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ABSTRACT 



A wireless, pecr-to-pcer, capability addressable network 
(22) is disclosed. The network (22) accommodates any 
number of peers (20). Network connections are formed 
based upon proximity between peers (20) and upon a needs 
and capabilities evaluation (82). Wireless communications 
occur at a sufficiently low power to form a detection zone 
(28) of less than about five meters for many peers (20). 

12 Claims, 8 Drawing Sheets 
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CAPABILITY ADDRESSABLE NETWORK 
AND METHOD THEREFOR 

RELATED PATENTS AND APPLICATIONS 

The present application is a continuation in part of U.S. 
patent application Ser. No. 08/729,207 filed on Oct. 15, 1996 
and issued on May 30, 2000 as U.S. Pat. No. 6,069,896 titled 
Capability Addressable Network And Method Therefore by 
Borgstahl et al. 

TECHNICAL FIELD OF THE INVENTION 

The present invention relates generally to data commu- 
nication networks. More specifically, the present invention 
relates to a peer-to-peer network in which node addressing 
is dynamically configurable. 

BACKGROUND OF THE INVENTION 

In a typical day many people come into contact with a 
massive number of electronically controlled devices. Such 
devices range from automobiles and appliances, to home 
and office equipment, and to telephones and televisions to 
name but a few. Many of these devices are required to move 
from time to time, and many of these devices are even 
portable. These devices provide a vast and diverse assort- 
ment of services for the people coming into contact with 
them. However, they suffer from a common problem related 
to user input and output (I/O). 

User I/O refers to components and processes used to 
communicate user-supplied data to an electronic device and 
to annunciate data from an electronic device so the data may 
be perceived by a user Although electronic devices provide 
a vast and diverse assortment of services, they tend to have 
redundant I/O. In other words, many such devices have 
displays, speakers, and the like at which data may be 
annunciated and have buttons, switches, keypads, and other 
controls at which user-supplied data may be communicated 
to the devices. In order to keep costs low and size small, user 
I/O capabilities often suffer. As a result, many electronic 
devices encountered in everyday life, and particularly many 
portable devices, are cumbersome and tedious to use 
because communicating data from a user to the devices is 
difficult and because provisions are unavailable for clearly 
annunciating data for a user's benefit. 

In theory, this user I/O problem could be ameliorated by 
better integrating electronic devices to ease data communi- 
cations therebetween. For example, a portable telephone 
could receive a facsimile (fax), but typically has no capa- 
bility to print the fax and no capability to communicate with 
a printer which may be able to print the fax. Likewise, a 
pager may receive a call-back phone number, but typical 
pagers have no capability to transfer the call-back number to 
a telephone from which the call-back can be made. User 
involvement is required to address these and many other 
data transfer issues. While many conventional data commu- 
nication or computer network architectures are known, the 
conventional architectures are unsuitable for the task of 
integrating a plurality of electronic devices which collec- 
tively provide a vast and diverse assortment of services. 

Conventional computer networks require excessively 
complicated setup or activation procedures. Such setup and 
activation procedures make the jobs of forming a connection 
to a new network node and making changes in connectibility 
permission cumbersome at best. Setup and activation pro- 
cedures are instituted, at least in part, to maintain control of 
security and to define network addresses. Typically, a system 
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administration level of security clearance is required before 
access is granted to network tables that define the network 
addresses. Thus, in conventional networks, many network 
users lack sufficient security clearance to activate and obtain 

5 addresses of network nodes with which they may wish to 
connect on their own. 

Once setup is performed, either directly by a user or by a 
system administrator, connections are formed when an ini- 
tiating node presents the network with the address of a 

30 network node to which a connection is desired. The setup or 
activation requirements of conventional networks force 
nodes to know or obtain a priori knowledge of node 
addresses with which they wish to connect prior to making 
the connection. Excessive user attention is involved in 

15 making the connection through setup procedures and during 
the instant of connection to obtain addresses. This level of 
user involvement leads to an impractical network imple- 
mentation between the everyday electronic devices with 
which people come into contact. 

20 Further, conventional computer networks tend to be infra- 
structure intensive. The infrastructure includes wiring, 
servers, base stations, hubs, and other devices which are 
dedicated to network use but have no substantial non- 
network use to the computers they interconnect. The use of 

25 extensive network components is undesirable for a network 
implementation between everyday electronic devices 
because an immense expense would be involved to support 
such an infrastructure and because it impedes portability and 
moyability of nodes. 

30 The use of wiring to interconnect network nodes is a 
particularly offensive impediment to the use of conventional 
networks because wiring between diverse nodes is not 
suitable when some of the nodes arc portable. Wireless 
communication links could theoretically solve the wiring 

35 problem. And, conventional wireless data communication 
networks are known. However, the conventional wireless 
networks do little more than replace wire lines with wireless 
communication links. An excessive amount of infrastructure 
and excessive user involvement in setup procedures are still 
required. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention 
may be derived by referring to the detailed description and 
45 claims when considered in connection with the Figures, 
wherein like reference numbers refer to similar items 
throughout the Figures, and: 

FIG. 1 shows a layout diagram depicting relationships 
between various peers in a wireless peer-to-peer data com- 
50 munication network configured in accordance with the 
teaching of the present invention; 

FIG. 2 shows a block diagram of hardware included in a 
peer; 

FIG. 3 shows a list of appliance circuits which may be 
included in the hardware illustrated in FIG. 2; 

FIG. 4 shows a list of relay interfaces which may be 
included in the hardware illustrated in FIG. 2; 

FIG. 5 shows a list of I/O devices which may be included 
60 in the hardware illustrated in FIG. 2; 

FIG. 6 shows a flow chart of tasks included in a capability 
addressable connection process performed by a peer; 

FIG. 7 shows a data format diagram of an exemplary 
need/capability message communicated from a peer to ini- 
65 tiate a setup connection; 

FIG. 8 shows an exemplary need table which identifies 
possible network service needs which might occur at a peer; 
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FIG.9 shows an exemplary capability tabic which iden- 
tifies possible network capabilities which may be provided 
by a peer; 

FIG. 10 shows a flow chart of a process service connec- 
tion procedure performed at a peer; 5 

FIG. 11 shows a flow chart of tasks included in a 
capability addressable connection process for initiating 
communications between peers; 

FIG. 12 illustrates a first example whereby the capability J0 
addressable connection process establishes communications 
between a computer and a personal presence identifier; 

FIG. 13 illustrates a second example whereby the capa- 
bility addressable connection process establishes communi- 
cations between a doorbell and the personal presence iden- 15 
tifier; and 

FIG. 14 is a diagram that illustrates a capability addres- 
sable connection between two peers. 

DETAILED DESCRIPTION OF THE DRAWINGS 20 

FIG. 1 shows a layout diagram depicting relationships 
between various peers (P) 20 in a capability addressable, 
wireless, peer-to-peer data communication network 22 con- 
figured in accordance with the teaching of the present 
invention. While FIG. 1 shows only a few peers 20, virtually 25 
any computer or microprocessor controlled electronic 
device throughout the world may serve as a peer 20. 
Accordingly, network 22 supports an unfathomable number 
of possible connections between peers 20. ^ 

As used herein, the term "peer-to-peer" is defined to mean 
having at least common portions of communications proto- 
col and/or capability and does not refer to equivalence of 
physical size, functional capability, data processing capacity 
or transmitter/receiver range or power. Each peer or com- 35 
munication node 20 of communications network 22 may 
establish a personal area network. For example, a first and a 
second of nodes 20 first find or determine that each other is 
a compatible node. Then, as a result of self-initiated 
processes, first and second nodes 20 form the personal 40 
network. First and second nodes 20 must detect that they are 
in a particular proximity to one another and if so a commu- 
nication link is established. This link may be accomplished 
by known RF techniques. When a link is established, first 
and second nodes 20 exchange what their needs and capa- 45 
bilities are. When needs and capabilities are not able to be 
satisfied or matched, one of first and second nodes 20 may 
alternately route the communications link to a third com- 
munication node 20. Put another way, a communications 
platform that includes at least two nodes having overlapping 5Q 
communications regions could also include means for 
exchanging needs and capabilities information between the 
at least two nodes for forming a communication network. 

Network 22 is desirably configured in a peer-to-peer 
architecture so that only a trivial amount of network-specific 55 
components are used. In the preferred embodiments, each 
peer 20 can initiate a connection with other peers 20 without 
servers being required to manage the connections. 
Moreover, peers 20 can freely move about, as indicated by 
direction arrows 24 in FIG. 1, without affecting the network eo 
structure or requiring the performance of reconfiguration, 
setup, or activation procedures. 

Free movement of peers 20 is further supported by using 
wireless communication links 26 as a physical transport 
layer in network 22. In the preferred embodiments, wireless 65 
communication links 26 are RF links operating in the higher 
regions of the microwave band so that small, lightweight, 
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inexpensive, omni-directional antennas may be used. 
However, other RF frequencies, optical links, and other 
wireless communication links known to those skilled in the 
art may be used as well. The specific protocols used in 
implementing wireless communication links 26 are not 
important to the present invention. Various TDMA, FDMA, 
and/or CDMA techniques known to those skilled in the art 
may be employed. However, all peers 20 in network 22 
desirably have the ability to communicate using the 
protocols, regardless of the capabilities and needs of the 
peers 20. 

FIG. 1 depicts a detection zone 28 surrounding each peer 
20. In the preferred embodiments, wireless communication 
links 26 for the vast majority of peers 20 are operated at a 
sufficiently low power so that a wireless communication 
range for a given peer 20 is limited to being less than 50 
meters, and more preferably to being less than about 5 
meters for the typical peer 20. The use of this degree of low 
power transmissions limits interference between indepen- 
dent connections which may share the wireless spectrum at 
different locations. Moreover, the use of this degree of low 
power transmissions is compatible with configuring a sub- 
stantial portion of peers 20 as portable devices. Those skilled 
in the art will appreciate that hand-portable electronic 
devices share the characteristics of being physically small, 
lightweight, and including a self-contained power source 
such as a battery. Extremely low power transmissions do not 
severely deplete the reserves of small batteries typically 
used in portable devices. 

While a peer 20 may potentially connect through network 
22 with a vast multitude of peers 20, the use of low power 
wireless communication links 26 limits the number of 
potential connections at any given instant in time to those 
peers 20 which are physically proximate to one another. In 
other words, only when a first peer 20 resides in the 
detection zone 28 of a second peer 20 and that second peer 
20 resides in the detection zone 28 of the first peer 20 can 
a connection through network 22 occur. 

Rather than specifying a network unique address to ini- 
tiate a connection, network 22 uses physical proximity along 
with a needs and capabilities evaluation (discussed below) to 
target a peer 20 with which a connection is desired. By not 
specifying a network unique address to initiate a connection, 
user involvement in making connections is reduced and 
network addressing becomes dynamically configurable. 
Such an addressing scheme is useful in exchanging data 
between devices a user carries and comes into contact with 
on a daily basis. 

Not all peers 20 are required to be portable devices. FIG. 
1 shows a wireline communication link 30 connecting a peer 
20' to a public switched telecommunication network (PSTN) 
32. Through PSTN 32, peer 20' may communicate with a 
vast assortment of remote devices 34, of which FIG. 1 shows 
only one. Peer 20* may be powered from a public power 
network (not shown) so that minimizing power consumption 
is not a significant design issue. While FIG. 1 depicts only 
PSTN 32 linking a peer 20 to a remote device 34, other local 
area network (LAN), wide area network (WAN) or commu- 
nication links known to those skilled in the art may connect 
a peer 20 to remote devices 34. Remote devices 34 may or 
may not themselves be peers 20. While network 22 uses 
proximity as a factor in targeting peers 20 to which connec- 
tions are formed, the use of routing, gateway or relaying 
peers 20* permits connections to be extended over great 
distances through the use of other networks. 

FIG. 2 shows a block diagram of hardware included in a 
peer 20. Peer 20 includes an antenna 36 configured to 



08/01/2002, EAST Version; 1.03.0002 



US 6,421,347 Bl 

5 6 

support wireless communication link 26. Antenna 36 Generally, task 58 allows a first peer 20 to determine 

couples to a transmit and receive section 38. Transmit and whether a second peer 20 is physically proximate to the first 

receive section 38 is compatible with the protocols peers 20 peer 20. Task 58 causes transmit and receive section 38 (see 

use to communicate with one another. Transmit and receive fig. 2) to monitor wireless communication link 26 (sec FIG. 

section 38 couples to a processor 40. Processor 40 couples 5 i) l0 determine whether a signal compatible with a protocol 

to a memory 42, an optional relay interface 44, an optional bcing uscd by network 22 (see FIG. 1) can be received. Due 

I/O section 46, and optional appliance circuits 48. t0 tnc above-described low transmission power levels uscd 

Processor 40 executes computer programs 50 which are by pecrs 2 0, when a signal is detected, the peer 20 sending 
stored in memory 42. Computer programs 50 define pro- tnc signal ^ i ocalc d near the receiving peer 20. 
cesses performed by processor 40 and peer 20. Memory 42 1fl or , . . . . 
additionally stores personalization data 52 and application 10 u When lask 58 fails t0 del ™ a selu P connection is 
data 54. Personalization data 52 characterize a user or owner bein S attempted, a query task 60 determines whether a 
of peer 20 and may change from user to user. ID codes, connection-seeking event has occurred. A connection- 
passwords, and PINs are examples of personalization data as seeking event causes a peer 20 to seek out a connection with 
are radio or TV channel presets, language preferences, and another peer 20. Connection-seeking events can be triggered 
speed dial telephone numbers. Application data 54 are 15 using a periodic schedule. For example, connections may be 
provided by performing peer applications, and may change sought out every few seconds. In this example, the schedule 
from moment to moment. A facsimile, a telephone number may call for more frequent periodic connection attempts 
received over a pager, data scanned in using a bar code from peers 20 which are powered from a public power 
reader, and a sound snippet received from a microphone or network and less frequent connection attempts from peers 20 
other audio source represent examples of application data. 20 which are battery powered. Connection-seeking events can 

FIG. 3 shows a non-exhaustive list of examples of appli- also be triggered upon the expiration of a timer or upon the 

ance circuits 48 which may be included in a peer 20. recei P l of othcr external information The other external 

Referring to FIGS. 2 and 3, appliance circuits 48 may be information can include information obtained through apph- 

configured as any type of a wide variety of everyday, ance circuits **• rela V interface 44 > or 1/0 scctl0D 46 ( see 

commonly encountered electronically controlled devices. 25 FIG 2 ) including user input. 

Thus, a peer 20 may, in addition to being a peer 20, be a If task 60 fails to determine that a connection-seeking 

personal digital assistant (PDA), smartcard, television, event has occurred, program control loops back to task 58. 

radio, CD player, tape player, copier, facsimile machine, If task 60 determines that a connection-seeking event has 

telephone, cellular telephone, cordless telephone, pager, occurred, process 56 performs a task 62. Task 62 initiates an 

watch, computer, point of sale (POS) terminal, automated 30 unsolicited setup connection. The setup connection is not 

teller, or other electronic device, addressed to any particular peer 20 of network 22. Rather, it 

FIG. 4 shows a non-exhaustive list of relay interfaces 44 ^ broadcast from the peer 20 making the attempt and will be 

which may be included in a peer 20. Referring to FIGS. 2 received by all peers 20 within the detection zone 28 (see 

and 4, relay circuits 44 may be configured as any of a wide FIG 1) of the broadcasting peer 20. As discussed below, the 

variety of relay, routing, or gateway devices known to those broadcast signal need not be answered by another peer 20 

skilled in the art. For example, a peer 20 may, in addition to even when another peer 20 is in detection zone 28. At this 

being a peer 20, be a modem which couples peer 20 to PSTN P oinl » the broadcasting peer 20 does not know if any other 

32 (see FIG. 1). Other relay interfaces 44 may couple a peer P ee r 20 can receive the broadcast signal, and the broadcast- 

20 to LANs or WANs. Still other relay interfaces 44 may in 8 P eer 20 does not know an y particular needs or capabili- 

couple a peer 20 modem to a satellite, a peer 20 cell phone ties of other peers 20 should other peers 20 be sufficiently 

to PSTN 32, a plain old telephone (POT) peer 20 to PSTN proximate so that a connection may be formed. 

32, or a peer 20 to another peer 20. Task 62 initiates a setup connection by broadcasting a 

FIG. 5 shows a non-exhaustive list of I/O devices 46 need/capability message 64, an exemplary format for which 

which may be included in a peer 20. Referring to FIGS. 2 45 is depicted in FIG. 7. Referring to FIG. 7, message 64 

and 5, I/O devices 46 may be classified into input devices includes an ID 66 for the peer 20 broadcasting message 64, 

and output devices. Input devices may include keyboards, an authorization key 68, a need specification 70, a capability 

pointing devices, optical scanners, microphones, and other specification 72, and can include other data elements. ID 66 

well known input devices. Output devices may include is desirably sufficiently unique within the domain of network 

printers, monitors, speakers, and other well known output 50 22 so that it may be used in an addressed service connection, 

devices. Thus, in addition to being a peer 20, a peer 20 may should the setup connection prove successful. Authorization 

be an I/O device 46. key 68 includes one or more data codes which may be used 

Those skilled in the art will appreciate that relay interface by a receiving peer 20 in performing an authorization 

section 44, I/O section 46 and appliance circuits 48 are not process. Needs specification 70 is a list of network needs 

mutually exclusive categories. For example, many devices 55 currently experienced by the broadcasting peer 20. Capabil- 

fall into multiple categories. For example, a computer con- i»Y specification 72 is a list of network capabilities which the 

sidered as an appliance may include both an I/O section and broadcasting peer 20 may provide to other peers 20 of 

a relay interface. Likewise, a relay interface may serve an network 22. 

I/O role. Needs specification 70 may be determined by consulting 

FIG. 6 shows a flow chart of tasks included in a capability 60 a need tabIe 74 » arj exemplary and non-exhaustive block 

addressable connection process 56 performed by a peer 20. diagram of which is depicted in FIG. 8. As illustrated in FIG. 

Process 56 is defined by a computer program 50 stored in 8, data codes may be associated with a variety of network 

memory 42 of peer 20 (see FIG. 2) in a manner well known service needs which a service -requesting peer 20 may expe- 

to those skilled in the art. In the preferred embodiments, all rience. 

peers 20 perform a process similiar to process 56. 65 One exemplary need is that of appliance personalization. 

Process 56 includes a query task 58 during which peer 20 In the appliance personalization need example, a PDA might 

determines whether a setup connection is being attempted. need to personalize nearby appliances. To satisfy this need, 



08/01/2002, EAST Version: 1.03.0002 



US 6,421,347 Bl 

7 8 

personalization data 52 (see FIG. 2) should be programmed message 64, After task 82, a query task 84 acts upon the 

into certain nearby appliances without user intervention. As result of the evaluation of task 82. If no internal capabilities 

a result, the certain appliances will always be programmed match needs indicated in an unsolicited message 64, and if 

with a particular user's personalization data whenever that no internal needs match capabilities indicated in an unso- 

uscr is near, without requiring action on the user's part, and 5 licited message 64, then neither peer 20 can be of service to 

regardless of prior persons who may have used the appli- the other. Program control loops back to task 60, and the 

ancCt " receiving peer 20 need not reply or otherwise acknowledge 

Other exemplary needs can include that of printing appli- the attempted setup connection, 

cation data 54 (see FIG. 2), displaying application data 54, At this point, the vast multitude of potential connections 

annunciating application data 54 at a speaker, routing con- 10 which a peer 20 may make within network 22 has been 

nectivity to the Internet or other network resources, POS greatly reduced in scope without the use of network-unique 

transactions, passage through secure areas or toll booths, and addressing. The low power transmission scheme excludes 

the like. most peers 20 in network 22 from being connectable at a 

Capability specification 72 may be determined by con- current instant because most peers 20 will not be proximate 

suiting a capability table 76, an exemplary and non- 15 one another. Of the few peers 20 which may be within each 

exhaustive block diagram of which is depicted in FIG. 9. As other's detection zones 28 (see FIG. 1), the scope of poten- 

illustrated in FIG. 9, data codes may be associated with a tial connections has been further limited through the autho- 

variety of network capabilities provided by a service- nation process of task 78 and needs and capabilities 

providing peer 20. For example, a service-providing peer 20 evaluation of task 82. Additional exclusions on the remain- 

capabilitv can be that of appliance personalization. Thus, a 20 ing potential connections are performed through a negotia- 

peer 20 may be capable of being personalized by personal- tion process carried on between a service -requesting peer 20 

ization data 52 (see FIG. 2). Other examples include capa- and a service-providing peer 20. 

bilities of printing, displaying, annunciating over a speaker, When task 84 determines that capabilities and needs 

relaying a connection through the Internet or other network, appear to be compatible, a query task 86 determines whether 

POS terminal, and unlocking a secured passageway, to name 25 this negotiation process is complete. If the negotiation 

a few. In general, potential capabilities are compatible with process is not complete, a task 88 establishes or otherwise 

potential needs. continues the setup connection in furtherance of the nego- 

Referring back to FIG. 7, need/capability message 64 tiation process by sending an addressed negotiation message 

includes those codes from tables 74 and 76 (see FIGS. 8-9) (not shown) to the peer 20 whose peer ID 66 (see FIG. 7) 

that currently apply. While a peer 20 may have more than was included in a just-received needs/capabilities message 

one need or capability at a given instant, nothing requires a 64. The negotiation message can have a form similar to that 

peer 20 to have multiple needs or capabilities. Moreover, of needs/capabilities message 64, but be specifically 

nothing requires a peer 20 to have both a network need and addressed to the other peer 20. 

a network capability. Message 64 serves as a need message 35 After task 88, program control loops back to task 60. 

if a network need is specified regardless of whether a Subsequent negotiation messages may, but need not, be 

network capability is specified and as a capability message received. If such subsequent negotiation messages indicate 

if a network capability is specified regardless of whether a that both peers 20 to the prospective connection have 

network need is specified. completed negotiation, a query task 90 determines whether 

Referring back to FIG. 6, after task 62 broadcasts message 40 the negotiation was successful. If the negotiation was not 

64 (see FIG. 7), program control loops back to task 58. successful, program control loops back to task 58, and no 

When task 58 eventually detects that a setup connection is service connection will result. However, if the negotiation 

being attempted by receiving a message 64, a task 78 was successful, a process service connection procedure 92 is 

performs an authorization process. Task 78 uses authoriza- performed. During procedure 92, a one-to-one, addressed 

tion key 68 (see FIG. 7) from message 64 to determine if the 45 connection is established between peers 20 to perform 

peer 20 attempting to setup a connection is authorized to network services. Upon completion of the service 

connect to the receiving peer 20. Task 78 allows an owner connection, program flow loops back to task 58. 

of a peer 20 to restrict access to the owned peer 20 through While nothing prevents capability addressable connection 

network 22. The authorization process of task 78 may be process 56 from relying upon user intervention during the 

used, for example, to restrict personalization capabilities of 50 setup connection process, user intervention is not required, 

an appliance to a small family group. Alternatively, a peer 20 Whether user intervention is required or not should depend 

having a POS capability may perform an extensive autho- upon the security and other considerations connected with 

rization process before permitting a transaction to take place. the nature of the peers 20 involved. For example, peers 20 

A peer 20 having a need may also qualify the receipt of involved in financial transactions can benefit upon user 

provided services depending upon the authorization process 55 intervention to ensure security. However, personalization of 

provided by task 78. user-owned appliances and many other connection scenarios 

After task 78, a query task 80 determines whether the need not rely on user intervention, 

authorization process 78 authorized the attempted setup FIG. 10 shows a flow chart of process service connection 

connection. If authorization is denied, program control loops procedure 92. Procedure 92 illustrates a collection of tasks 

back to task 60. The receiving peer 20 need not reply or 6 o which can be performed at a service-providing peer 20 in 

otherwise acknowledge the attempted setup connection. support of a service connection. Not all peers 20 need to be 

If authorization is accepted, a task 82 evaluates peer needs able to perform all the tasks depicted in FIG. 10. Likewise, 

with peer capabilities. In other words, task 82 causes the many peers 20 may include other tasks which suit the nature 

message -receiving peer to compare its available capabilities of those particular peers 20. 

(if any) to any needs listed in a received unsolicited need/ 65 Procedure 92 performs a task 94 to provide a network 

capability message 64 (see FIG. 7) and to compare its relay, router, or gateway capability for a service-receiving 

available needs (if any) to any capabilities listed in the peer 20 of network 22 through an established service con- 



08/01/2002, EAST Version: 1.03.0002 



US 6,421,347 Bl 

9 10 

ncction. During task 94, a service-providing peer 20 relays FIG. 11 is a flow chart providing further detail of the 

data communications between the connected peer 20 and a capability addressable coupling process as shown in FIG. 6. 

remote device 34 (see FIG. 1). After task 94, program flow FIG. 11 illustrates a method of initiating a communication 

returns to process 56 (sec FIG. 6). Task 94 may be used to link between first and second electronic devices or first and 

extend the service connection to the Internet or other net- 5 second peers 20. Referring briefly to FIGS. 1, 2, and 6, task 

work. 58 causes transmit and receive section 38 to monitor wire- 

Procedure 92 performs tasks 96 and 98 to provide a user less communication link 26 to determine whether a signal 

input capability for a service-receiving peer 20 of network compatible with a protocol being used by network 22 can be 

22 through an established service connection. During task received. In particular, task 58 of FIG. 11 indicates that a 

96, the service-providing peer 20 collects user input from its 10 setup connection or coupling process in transmitting a 

I/O section 46 (see FIG. 2). During task 98, the service- beacon message from a first peer 20 is received by a second 

providing peer 20 sends the collected user input data to the peer 20. The beacon message transmitted by the first peer 20 

connected service-receiving peer 20. After task 98, program is an unsolicited message that is broadcast to any listening 

flow returns. Tasks 96 and 98 may be used to control or electronic device. The type of information transmitted in the 

program appliances from a PDA or other device which may 15 beacon message is not a limitation of the present invention, 

have enhanced user input capabilities. In other words, the beacon message may or may not include 

Procedure 92 performs a task 100 to provide a user output all of the elements in need/capability message 64 as illus- 

capability for a service-receiving peer 20 of network 22 trated in FIG. 7. By way of example, the beacon message 

through an established service connection. During task 100, could only include the peer ID 66 portion of need/capability 

the service-providing peer 20 receives data generated from 2 o messa S e 64 in order 10 save bandwidth and power when 

the service-receiving peer 20 over the service connection transmitting data. Thus, the first peer 20 transmits a beacon 

and annunciates the data at an output device in its I/O section message, i.e., the identity of the first peer 20 as contained in 

46 (see FIG. 2). The data may be annunciated in an audibly peer ID 66, as an uasolicited periodic message independent 

or visibly perceivable format or in any other format per- of whether any other electronic device is within a close 

ceivable by human senses. After task 100, program flow 25 enough proximity to receive the message, 

returns. Task 100 may be used to annunciate data collected Task 78Aof FIG. 11 causes second peer 20 to perform an 

in a portable peer 20 at a non-portable annunciating device. authorization of the identity message received from the first 

Alternatively, task 100 may be used to annunciate data peer 20. If authorized to establish a communications link as 

generated by a stationary appliance with limited I/O capa- determined by task 80A, second peer 20 sends or transmits 

bility at a portable annunciating device. 30 an associate message as indicated by task 81 to first peer 20. 

Procedure 92 performs a control appliance process 102 to Thus, second peer 20 acknowledges receipt of the identity of 

support the controlling of appliances. Tasks 104, 106, and first peer 20 based on authorization of the second peer 20 to 

108 of process 102 are performed to program aD appliance communicate with the first peer 20 by transmitting an 

peer 20 with personalization data 52 (see FIG. 2). During associate message from second peer 20. If not authorized to 

task 104, a service-providing peer 20 gets personalization 35 establish a communications link, no associate message is 

data 52 from the connected, service-receiving peer 20 using transmitted and second peer 20 returns from task 80A (see 

the service connection. Next, task 106 translates the network FIG. 11) to task 60 (sec FIG. 6). 

compatible personalization data 52 into a format suitable for The associate message sent by the second peer 20 to the 

the specific appliance to be programmed with personaliza- first peer 20 confirms that second peer 20 is authorized to 

tion data 52. It should be noted that not all personalization 40 communicate with first peer 20 based on the transmitted 

data 52 available in a service -receiving peer 20 needs to be identity of the first electronic device. First peer 20 receives 

applicable to all appliances. Thus, task 106 can use as much the associate message and moves from task 61 to task 78B. 

of personalization data 52 as applies to the specific appli- Task 78B (also see task 78 in FIG. 6) causes first peer 20 to 

ance. After task 106, task 108 causes the appliance to be determine whether authorization is granted for the first peer 

programmed with the translated personalization data 52. 45 20 to establish communications with the second peer 20. If 

After task 108, program flow returns. authorization is granted then the first peer 20 moves from 

Tasks 110, 112, 114, and 116 of process 102 are performed task 80B to task 63 (FIG. 11). Task 63 causes first peer 20 

to allow a user to easily control an appliance. These tasks to send or transmit an associate confirm message to second 

can be performed on a PDA, for example, which has a peer 20. Thus, first peer 20 acknowledges both a receipt of 

display and user input capability exceeding the user I/O 50 the associate message from second peer 20 and a granted 

capabilities typically found on appliances. In this case, an authorization of first peer 20 to communicate with second 

appliance is a service-receiving peer 20 while the PDA is a peer 20 by transmitting an associate confirm message. When 

service -providing peer 20. During task 110, the service- second peer 20 receives the associate confirm message in 

receiving peer 20 uploads an appliance control computer task 83, the two-way communications link between first peer 

program to the connected service-providing peer using the 55 20 and second peer 20 is established, 

service connection. Next, during task 112 the service- . At this point, a communication link has been initiated and 

providing peer 20 executes the just-uploaded computer established between the first and second electronic devices 

program. Task 112 causes the service-providing peer 20 to and they are ready to communicate additional information 

become specifically configured to provide a desirable user between themselves. Task 82 in FIG. 11 corresponds with 

interface for the specific appliance being controlled. Next, 60 task 82 in FIG. 6, which causes an exchange of needs and 

during task 114 control data are received at the service- capabilities between first peer 20 and second peer 20. The 

receiving peer 20 over the service connection. The control first peer 20 transmits its needs and capabilities to the second 

data originated from user input supplied through the control peer 20 and the second peer 20 transmits its needs and 

computer program being executed on the service-providing capabilities to the first peer 20. A need of peer 20 is defined 

peer 20. After task 114, task 116 controls the subject 65 as a need for service. It may be that the need for service is 

appliance in accordance with the control data received in an operation that is desired to be performed on the data of 

task 114. After task 116, program flow returns. peer 20 but peer 20 is not capable of performing the desired 



08/01/2002, EAST Version: 1.03.0002 



US 6,421,347 Bl 
11 12 

option. For example, it .ay be desired that thedaj be ^ 7Z°lZ7^T^l 
W^^^nttofoT^t^fZ comP«"r £ directories, font styles, files, etc which is 

enCry f ,e ^ r nf e r r 20 th ^ encSn circuU ha " presence identifier 122. During task 104, computer 120 gets 

circuit, n* peer 20 with ^ ^r^n c £ u an £ ersonalizalion data 52 from the service connection with 

capability of encrypting data mat can oe oucicu o» « |,„_„ n _i „„„„„ identifier 122 Next, task 106 trans ates 

operation to other peers without the encryption circuit „ ££££££ ^Z^L^Sl^baoMl 

FIG. 12 illustrates a first example whereby the capability the -^J^ P ter m ^ 

addressable connection process establishes communication ™S °^ " particular user's personalization data 

between two peers 20 U.. a computer 12 and, .persona ^^^l^ vl ^l eaB ^m m i 

presence identifier 122. Personal presence identifier 122 is a ™ computer 120, without requiring action on 

specific peer 20 such as an electronic watch, an electronic 15 autamed to use e p ^ ^ 

munication links 26. nr .„ nce identifier 122 is within detection zone 28 of 

■n,a^^li«rf«l-P^«^g^* SI'S!* as long as computer 120 and per- 
computer 120 and personal presena; identifier m each P .^.^ ^ ^ ^ dose proximity> 

execute query task 58 of process 56 (FIG. 6). task » 25 J 12 „ jns active to the ^ r identified by 

determines that computer 120 and personal presence iden- computer ™™™ Hq ter secu . 

tifier 122 have transmitted an unsolicited and periodic becax Mss communication 

beacon message in attempting to setup a connection and are is further ^ ^ ^ ^ 

residing within each others detection zone 28 . T^sk 5 8 „ js bro J n when perMnal preMnce identifier 122 is 

causes transmit and receive section 38 (FIG. 2) to monitor 30 P . h , proximity with computer 120. 

wireless communication link 26 to determine whether a removed from the cto« p y ^ broke[) 

signal compatible with a protocol being used by communi- Wirele * commun .^r 122 

desenbed m FIG. 11). . InhlkhP H ml com and a personal presence identifier 122. Door entry system 

Once the personal area ^0 is In electronic device such as a doorbell system that has 

puter 120 and personal presence identifier 122 are autno r „ mm , ln ; cations oro tocol of peer 20. By way of 

rized to communicate with each other, needs specification 70 40 is ex* mall v mounted at the 

and capability specification 72 * "^"^^^ IZt^o^L. When door entry system 130 and 

64 (FIG. 7) are exchanged. In other words, computer 120 towt en ry o ^ 

transmits needs specification 70 and capability specification hey are interlinked via, for example, RF 

«-«tal^rf«^^»3^4™o 7 g 45 ntrnections/repLnted as wire.ess communication 

V £ 70 L ^canaWlitv ffijfflG 9) contains determines that door entry system 130 and personal presence 

that computer 120 needs performed The servic 1 may communication link 26 to determine whether a 

include a function that computer 120 is not capable of T^^Xte with a protocol being used by communi- 

performing or authorized to perform, such as providing a FIG 1) is received. Through a self- 

password tha, enables or allows a user access ^.ofiles &U. 60 ^ ne work 22 ( ) ^ ^ ^ 

and programs stored on computer 120. Thus, personal pres ide P mifier 12 2 transmit associate messages and 

ence identifier 122 establishes communications network 22 ^J c Snfl^ 1 mesM ^ M io establishing a personal area 

(FIG. 1) with computer 120 arc .in action prov^e ~~ks d e Jbed in FIG. 11) . 

authorization tha, -^.s compuU .12 0 o have an acuve , ^ ^ ^ 

keyboard and screen and provide access to use " s computer f identifier 122 are 
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cation 70 and capability specification 72 of need/capability shake process that initiates and establishes link 26 Ttas, the 

messaae 64 (FIG 7) are exchanged. Door entry system 130 true .dent.ty of the person placing the call s available for 

^perl™ presence identifier 122 have several possible display as "true caller ID" instead of displaying the name of 

omtons wScn operating together. A firs, option is that door the person who subscribed to the service at the calling 
emTsystem 130 real peer ID 66 (FIG. 7) of personal 5 station. I. should be noted that "true caller ID can also 

presence identifier 122 to determine the identity of the provide a true identity for users of two way rad.os, fax 

person wearing personal presence identifier 122. To enhance machines, pagers, or the like. 

security of the residence, the identity of the person could FIG. 14 also illustrates a fourth example of the capability 

then be displayed on a service-providing peer 20 within the addressable connection process that establishes communi- 
residence which is capable of displaying information JQ cations between two peers 20, i.e., a peer 132 as a tour 

received from door entry system 130. Service-providing display device and personal presence identifier 122. Exhibits 

peer 20 would log the identity found in peer ID 66 (FIG. 7) along a tour path include the tour display devices which 

of each person having a personal presence identifier 122 that establish link 26 when the user with the personal presence 

attempts a setup connection via door entry system 130. identifier 122 comes in close proximity with the tour display 
A second option involves receiving a note intended only 15 device. Through a self-initiated process the tour disp ay 

for the person residing at the resident. For instance, a devices and personal presence identifier 122 each attempt :to 

delivery service may want to leave a private message setup a connection by transmitting unsolicited and periodic 

explaining possible options after finding no one at home. beacon messages. Associate messages and associate confirm 

After establishing the identity of the delivery .service per- messages are exchanged between the tour disp ay devices 
sonnel who is wearing personal presence identifier 122, door 20 and personal presence identifier 122 to establish link 26 (see 

entry system 130 could receive a message entered though tasks described in FIG. 11). 

personal presence identifier 122 by the delivery service Additional information that includes personalization data 

personnel The message would then be displayed on a 52 (FIG. 2) is then transferred from personal presence 

service-providing peer 20 within the residence which is identifier 122 to the tour display device transferred during 
capable of displaying information received from door entry 25 task 104 (FIG. 10). Personalization data 52 contains infor- 

system 130 mation such as tour language preference, age of user, type of 

' A third option involves the home owner leaving a mes- tour desired, etc. In return, the tour display device provides 

sage for the delivery service personnel that has a specific the appropriate information about the exhibit in accordance 

identification designator programmed in the personal prcs- with the criteria presented in personalization data 52_ When 

ence identifier 122. For instance, the resident may want to 30 *<= user leaves the range of the cxh.b.t, link 26 is broken and 

leave a private message with the delivery service after the delivery of information is suspended. Tour display 

establishing the identity of the person wearing personal devices have applications for trade shows, museums, theme 

presence identifier 122. By providing or receiving messages parks, building directories, among other, and provide infor- 

at a location near the cntrv of a residence, door entry system mation that is specific to the user and the information 

130 enhances the security of the resident by allowing private 35 contained in personalization data 52 of personal presence 

messages to be communicated. A wireless communication identifier 122. 

link 26 is automatically established when a user with the FIG. 14 also illustrates a fifth example of the capability 
personal presence identifier 122 is within detection zone 28 addressable connection process that establishes commum- 
of door entry system 130. The identity of the user with the cations between two peers 20, i.e., a peer 132 as a recording 
personal presence identifier 122 is available to the residence 40 device (audio capture pen) and personal presence identifier 
of the home serviced by door entry system 130. 122. Through a self-initiated process the recording device 
HG 14 illustrates a third example of the capability and personal presence identifier 122 each attempt to setup a 
addressable connection process that establishes communi- connection by transmitting unsolicited and periodic beacon 
cations between two peers 20, i.e., a peer 132 as a telephone messages. Associate messages and associate confirm mes- 
and personal presence identifier 122. Many telephone ser- 45 sages are exchanged between the recording device and 
vice providers offer a feature of "caller identification (ID)" personal presence identifier 122 to estabhsh link 26 (see 
that is intended to provide a visual display of the name of the tasks described in FIG. 11). Either high-fidelity audio or 
party at the calling station. Instead, the "caller ID" feature voice can be captured and digitally recorded by the record- 
actually identifies the name of the person who subscribed to ing device. For instance, a primary channel of the audio 
the service at the calling station which may not be the name so signal is sampled to generate a digital recording and a 
of the person who is placing the call. Further, another feature secondary channel is checked for audio signaling informa- 
referred to as "call blocking" denies phone connections with tion. The audio information from both the primary and 
calls made from specific phone numbers. However, the secondary channels can be transferred to another peer 20 
selective call filtering based on specific phone numbers does having sufficient memory capabilities that provides storage 
not prevent unwanted individuals from completing the 55 of the audio information. 

phone call 14 also illustrates a sixtn example of the capability 

With the telephone, i.e., peer 132, and personal presence addressable connection process that establishes communi- 

identifier 122 in close proximity to each other, capability cations between two peers 20 i.e., a peer 132 as an elec- 

addressable network 22 (FIG. 1) can be established. tronic take-a-mimber device and personal presence identifier 

Through a self-initiated process the telephone and personal 60 122. Through a self-initiated process the electronic take-a- 

nresence identifier 122 each attempt to setup a connection by number device and personal presence identifier 122 each 

ransmitting unsolicited and periodic beacon messages. attempt to setup a connection by transmitting unsolicited and 

Associate messages and associate confirm messages periodic beacon messages. Assoc.ate messages and associate 

exchanged between the telephone and personal presence confirm messages are exchanged between the electronic 

identifier 122 establish link 26 (see tasks described in FIG. 65 take-a-number device and personal prese^e identifier 122 

11) The true identity of the user is transferred from personal to establish link 26 (see tasks described in FIG. 11) when the 

presence identifier 122 to the telephone during the hand- two peers are in close proximity to each other. Certain 
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services are provided in a sequential order based on a queue broadcast. The viewing of the movie or event can be moved 

system. Once personal presence identifier 122 forms link 26 to locations where cable is not available. In addition, the 

and is registered with the electronic take-a-number device, compressed movie format and required key for decoding the 

information is transferred to personal presence identifier 122 compressed format provide the cable company with protcc- 

by the electronic take-a-number device. The information, for 5 tion in verifying the number of times the movie or event is 

example, includes position in the queue, expected wait time, replayed. 

notification of reaching the head of the queue, registration in FIG. 14 also illustrates a ninth example of the capability 
other queues when necessary, financial cost of an expected addressable connection process that establishes communi- 
transaction, etc. cations between two peers 20, i.e., a peer 132 as a personal 
FIG. 14 also illustrates a seventh example of the capabil- 10 kiosk system and personal presence identifier 122. Through 
ity addressable connection process that establishes commu- a self-initiated process the personal kiosk system and per- 
meations between two peers 20, i.e., a peer 132 as a security sonal presence identifier 122 each attempt to setup a con- 
alarm system and personal presence identifier 122. nection by transmitting beacon messages. Associate mcs- 
Presently, merchandise protected by a magnetic strip is ^ges and associate confirm messages are exchanged 
detected at a sensing point and activates an alarm when the 15 between the recording device and personal presence identi- 
magnetic strip is not removed after the merchandise was 15 fier 122 t0 f ^hsh link 26 (see tasks described m FIG. 11) 
B " , * . F . . . . u in response to the unsolicited and periodic beacon messages, 
purchased. Alternatively, the present invention allows mer- * \ ° 
u a- ♦ u , /j u„! A^ t ;^ ™„„ Once link 26 has been established the user who carries 
chandise to be protected by a passive device having mag- ^ m exch information with 

netic information or a unique Universal Product Code (UPC) P £ # The user ^ for inf * rmati receives 

barcode that can be deactivated without removing the pas- 20 ^^ion, and carries on transact i 0 ns via personal pres- 

sive device from the merchandise. The self-closing transac- ence identifier U2 in communication with the kiosk. Other 

tion system allows purchases to be made without interven- users can alsQ engage in conversalions with the kiosk 

tion of the sales clerk which reduces merchandising cost and through their personal presence identifier 122. Thus, a single 

eliminates time waiting in lines to make the purchase. kiosk exchanges information with multiple users through 

To initiate the purchase transaction, the security alarm 2 s personal presence identifiers 122. It should be noted that the 

system and personal presence identifier 122 each attempt to kiosk can also represent building directory systems, auto- 

setup a connection by transmitting beacon messages. Asso- mated teller machines, terminals mounted on shopping carts, 

ciatc messages and associate confirm messages arc or the like. It should be noted that personal presence 

exchanged between the security alarm system and personal identifier 122 and the kiosk can operate as an actual time 

presence identifier 122 to establish link 26 (sec tasks 30 billing system if desired. Through a self- initiated process the 

described in FIG. 11) in response to the unsolicited and actual time billing system and personal presence identifier 

periodic beacon messages. The user of personal presence 122 each attempt to setup a connection by transmitting 

identifier 122 scans the magnetic code or barcode attached beacon messages. Associate messages and associate confirm 

to the merchandise that is being purchased and also provides messages are exchanged between the recording device and 

authorization for a financial transaction. Authorization in the 35 personal presence identifier 122 to establish link 26 (see 

form of public and private cryptographic keys provides tasks described m FIG. 11) in response to the unsolicited and 

security during the financial transaction during which funds periodic beacon messages. 

are transferred from a banking institution to the merchant. By now it should be appreciated that the present invention 

The three-way transaction involving the banking institution, provides an improved capability addressable network and 

the merchant, and the user of personal presence identifier 40 corresponding method. This network is suitable for inter- 

122 is completed by notifying the merchant and personal connecting a plurality of everyday electronic devices, 

presence identifier 122. Further, upon completion of the including movable and portable devices that provide a vast 

financial transaction the sensing point is programmed to and diverse assortment of services. A priori activation and 

allow the passive device attached to the purchased merchan- setup procedures are not required in this network because no 

dise to pass the sensing point without activating the alarm. 45 network specific equipment requires network addresses in 

FIG. 14 also illustrates an eighth example of the capability order 10 make connections. Consequently, a minimal amount 

addressable connection process that establishes communi- of user involvement is needed to make connections to peers, 

cations between two peers 20, i.e., a peer 132 as a Video and peers may make connections to new peers as a routine 

Cam Recorder (VCR) movie system and personal presence matter. Network node addressing is dynamically config- 

identifier 122. Through a self-initiated process the VCR 50 urable because network connections are formed based upon 

movie system and personal presence identifier 122 each proximity and upon a needs and capabilities evaluation 

attempt to setup a connection by transmitting beacon mes- rather than on unique network- wide address encoding, 

sages. Associate messages and associate confirm messages What ^ claimed is: 

are exchanged between the VCR movie system and personal 1- A method of establishing connectivity in a data corn- 
presence identifier 122 to establish link 26 (see tasks 55 munication network, comprising the steps of: 
described in FIG. 11) in response to the unsolicited and transmitting unsolicited messages from first and second 
periodic beacon messages. peers for reception by another peer; 

Once link 26 has been established a pay-per-view movie comparing an identity of the first peer that is included in 
in compressed format is released by the cable company and an unsolicited message received by the second peer 
stored in the VCR movie system. The compressed format 60 with an authorization key of the second peer to provide 
reduces bandwidth and cost in transmitting the pay-per-view authorization for the second peer to establish a corn- 
movie. Personal presence identifier 122 then communicates munication link with the first peer; 
with the cable company via the infrastructure such as a comparing an identity of the second peer that is received 
cellular phone (not shown) to receive a key for decoding the by the first peer with an authorization key of the first 
compressed format of the received movie. The VCR movie 65 peer to provide authorization for the first peer to 
system provides the convenience of viewing the pay-per- establish said communication link with the second 
view movie at times other than when the movie or event was peer; and 
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establishing connectivity in the data communication net- 
work after authorizing the first and second peers. 

2. The method of claim 1, further including the step of 
exchanging a first need and a first capability for executing a 
service from said first peer with a second need and a second 
capability from the second peer. 

3. The method of claim 2, further comprising the steps of: 
evaluating the first need and the first capability of the first 

peer by the second peer; and 
processing an addressed service connection in the second 
peer in response to the evaluating step. 

4. The method of claim 3, further comprising the steps of: 
uploading a computer program from the second peer to 

the first peer, the computer program defining a process 
for controlling the first peer; and 
executing the computer program at the first peer. 

5. The method of claim 4, further comprising the step of 
receiving control data from the second peer over the 
addressed service connection, wherein the control data is 
used by the computer program to control the first peer. 

6. The method of claim 1 wherein the steps of: 
transmitting unsolicited messages from first and second 

peers for reception by the another peer; 

authorizing the second peer to establish the communica- 
tion link with the first peer; and 

authorizing the first peer to establish the communication 
link with the second peer occur without manual inter- 
vention. 



10 



25 



7. The method of claim 1, wherein the step of establishing 
connectivity between the first peer and the second peer in the 
data communication network occurs when the first peer is 
within about 50 meters of the second peer. 

8. The method of claim 1, further comprising the steps of: 
receiving at a third peer an unsolicited second beacon 

message from the second peer; and 
authorizing the third peer to establish a second commu- 
nication link with the second peer based on the third 
peer verifying that the identity of the second peer is 
included in an authorization key of the third peer. 

9. The method of claim 8, wherein the connectivity in the 
data communication network includes relaying, at the sec- 
ond peer, data between the first peer and the third peer. 

10. The method of claim 1, wherein the second peer 
receives personalization data from the first peer. 

11. The method of claim 10, wherein the personalization 
data is selected from a group consisting of identification 
codes, passwords, identification numbers, radio presets, tele- 
vision presets, language preferences, and telephone num- 
bers. 

12. The method of claim 11, further comprising the steps 

of: 

storing the personalizing data at the second peer; and 
programming the second peer with the personalizing data. 
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An internet-protocol based anonymous trading system 
which enables traders to identify bids and offers which they 
are eligible to trade based upon a color coded methodology 
which gives the trader credit preference information about 
the potential counterparty while still maintaining the ano- 
nymity of the potential counterparty. To that end, each bid or 
offer is prescreened against all possible counterparties' v 
credit information in the system and each counterparty sees 
a unique color coded trading interface based upon their 
particular credit preference combinations and the others in 
the system. The system then shows all prices in the system, 
and the color-coding tells the trader which prices he is able 
to trade, and also shows him the full depth of the market, 
including those the trader is unable to trade. 
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SYSTEMS, METHODS AND COMPUTER 
PROGRAM PRODUCTS FOR ELECTRONIC 
TRADING OF FINANCIAL INSTRUMENTS 

CROSS-REFERENCE TO RELATED 5 
APPLICATION 

This application claims benefit of co-pending U.S. Pro- 
visional Application No. 60/062,410, entitled "Systems and 
Methods for Electronic Trading of Financial Contracts," and 
filed Oct. 14, 1997. In addition, the present application is 
related to the following co-pending, commonly assigned 
U.S. applications, each of which is incorporated by reference 
as if set forth in full: 

"Systems, Methods And Computer Program Products For 15 
Subject-Based Addressing In An Electronic Trading 
System," filed Oct. 12, 1998, and accorded application 
Ser. No.: 09-169,767; 
"Systems, Methods And Computer Program Products For 
Monitoring Credit Risks In Electronic Trading 20 
Systems," filed Oct. 12, 1998, and accorded application 
Ser. No.: 09/169,878; and 
"Switch Engine For Risk Position Discovery In An Elec- 
tronic Trading System," filed Oct. 12, 1998, and 
accorded application Ser. No.: 09/169,879. 25 

FIELD OF THE INVENTION 

The present invention generally relates to brokerage sys- 
tems and methods, and more particularly, to the electronic ^ 
trading of financial instruments such as derivatives. 

BACKGROUND OF THE INVENTION 

In recent years, commodity exchanges have become more 
and more dependent upon electronic trading systems. The 35 
older manual methods by which trades were conducted have 
given way to advanced computer systems that have gener- 
ally mimicked the manual methods of old. These relatively 
new electronic trading systems have many advantages over 
the manual systems, including the ability to provide such 40 
features as greater accuracy, reduced labor cost, real time 
market information, more efficient communications over 
greater distances, and automated record keeping. However, 
because the markets in which these commodities are being 
traded are so vastly different from the descriptions of the 45 
instruments to the transaction methodologies, electronic 
trading systems are generally limited to a specific market 
such as futures, cash, oil, stock, securities, etc., and some- 
times even to a specific commodity within a single market. 

An example of one such automated trading system 50 
designed for the anonymous trading of foreign currencies is 
described in U.S. Pat. Nos. 5,077,665 and 5,136,501, both 
issued to Silverman et al. and assigned to Reuters Limited of 
London. In the Silverman et al. system, a single central host 
computer maintains a central database that may consist of 55 
the trading instruments available for trade, credit 
information, and various bids and offers that are present 
throughout the system. The host computer may then use this 
information to match active bids and offers based on match- 
ing criteria which may include the gross counterparty credit 60 
limit between counterparties to a potential matching 
transaction, price, and available quantity. To that end, each 
client site may establish, and may subsequently vary or 
reset, a credit limit for each possible counterparty. The credit 
limits may be used by the host computer to establish the 65 
gross counterparty credit limit for each possible pair of 
parties and which may be equal to the minimum of the 
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remaining credit (i.e., initial credit limit less any applicable 
transactions that have already been executed) from a first 
party to a second party and from the second party to the first 
party. The host computer may block completion of an 
otherwise eligible matching transaction between a given pair 
of potential counterparties when the transaction has an 
associated value in excess of the applicable gross credit 
limit. In the Silverman et al. system, the various client site 
computers (also referred to as keystations) merely maintain 
and display a restricted subset of the information available 
at the host computer such as a predetermined number of the 
best bids and offers, and communicate credit and other 
transaction orientated information to the host computer for 
execution. However, in an attempt to preserve the anonymity 
of the parties, the client sites may not have access to the 
credit limits set by their possible counterparties, or even to 
the identification of any other party to a particular transac- 
tion until after a transaction has been completed. 

Thus, in the Silverman et al. system, confidential coun- 
terparty credit limit data is apparently maintained and uti- 
lized as part of the trade matching process by the central host 
computer. As a consequence, each client site may not have 
the ability to determine, prior to committing to buy or sell at 
a displayed price from one or more anonymous 
counterparties, whether it is in fact eligible to respond to any 
of the bids or offers currently being displayed. Further, the 
credit limit appears to be merely a cap value (or credit line) 
on the amount of trading one party will enter into with 
another party. It has little to no relationship to the credit risk 
the other party represents since the financial commitment 
associated with the fmancial instruments traded with this 
system ends at the consummation of the underlying contract. 
Thus, a cap value may be sufficient in this particular 
circumstance The central host computer may not utilize the 
credit information until after a match has been found 
between counterparties to determine if the counterparties 
have sufficient credit with one another to execute the trade. 

Consequently, unless a trader attempts to execute a trade 
at the best price currently displayed on the trader's screen, 
the trader using one of the anonymous matching systems 
may not know whether the trader has credit with, and is 
willing to extend credit to, the anonymous counterparty 
offering (i.e., bidding) the best price currently displayed on 
the trader's screen. Thus, the trader does not know whether 
any attempt to buy or sell at the displayed price may be 
subsequently invalidated by the system for lack of such 
credit. The Silverman et al. system also fails to provide for 
dialogue between the parties, much less anonymous dia- 
logue which may facilitate the execution of a trade that 
might otherwise not occur. 

Reuters Limited has apparently expanded the system 
described in Silverman et al. to include Forward Foreign 
Exchange contracts which are derivative instruments. 
However, as opposed to offering a settlement risk system 
that enables credit analysis prior to face-to-face settlement, 
the Reuters Limited system introduces the concept of soft 
matching which makes trades on the basis of credit risk 
rather than settlement risk. Thus, a trade is not confirmed 
until both parties obtain subsequent credit approval. Either 
party can cancel the transaction under the guise of no credit 
available to the counterparty once they know who is the 
counterparty. Accordingly, the Reuters Limited system is 
reportedly an unpopular solution to derivative trading via an 
electronic trading system. 

Another automated trading system is disclosed in U.S. 
Pat. No. 5,375,055 issued to Togher et al. and assigned to 
Foreign Exchange Transaction Services, Inc. The Togher et 
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al. system is an anonymous trading system which may 
identify the best bids and offers from those counterparties 
with which each client site is currently eligible to deal, while 
maintaining the anonymity of the potential counterparty and 
the confidentiality of any specific credit limitations imposed 5 
by the anonymous potential counterparty. This system is 
apparently designed to run as a closed system, with dedi- 
cated desktop terminals connected to various local computer 
centers, which are in turn connected to regional computers. 

In the Togher et al. system, each client site may only be 10 
able to view one foreign currency at a time per screen The 
Togher et al. system is further limited by the fact that each 
client site may provide the system with only limited credit 
information for each potential counterparty (for example, a 
one bit flag indicating whether a predetermined limit has 15 
already been exceeded), and by the fact that each bid or offer 
for a particular type of fmancial instrument is apparently 
prescreened by the system for compatibility with that limited 
credit information before calculating an anonymous deal- 
able price for presentation to the traders dealing with that 20 
particular fmancial instrument. The prescreening in Togher 
et aL is a simple check to determine whether any credit 
remains between the two counterparties to the potential 
transaction, and thus may be performed using a simple 
yes/no preauthorization matrix. 25 

The preauthorization matrixes may be maintained at each 
of the several regional nodes (also referred to as distributed 
nodes) of a distributed processing communication network, 
with each such regional node being connected by corre- 
sponding individual links of the communications network to 30 
the respective client sites for which it is responsible for 
distributing market information including customized deal- 
able bid and offer prices, and global best prices. 

The sensitive credit limit data indicating how much credit 35 
a particular client site is willing to extend to each possible 
counterparty is preferably maintained at an access node 
associated with that particular client, and a simple yes/no 
indication of whether the entity (for example, a trader, a 
trading floor, or a bank) associated with that particular client 40 
site is willing to transact business with a particular coun- 
terparty is transmitted to the other nodes of the communi- 
cations network. 

To further limit the data received and processed by each 
of the relevant regional node computers (i.e., the regional 45 
nodes closest to the particular client site and/or closest to the 
particular counterparty), merely the changes in the credit 
state between a particular client site and a particular coun- 
terparty (i.e., that credit is no longer available or credit is 
now available) may be transmitted to the distribution nodes, 50 
and any credit state information relevant to transactions 
between two client sites both associated with other distri- 
bution nodes may be altogether ignored. 

In the Togher et al. system, if either of the two applicable 
credit limits has not previously been exceeded between a 55 
particular pair of counterparties, then the system displays the 
entire bid or offer as a dealable transaction, but apparently 
permits each client site to block any above-limit portion of 
any resultant buy or sell transaction during a subsequent deal 
execution/verification process. This may, however, add addi- 60 
tional time consuming steps for the users of the Togher et al. 
system. Alternatively, possibly at the option of the party by 
or for whom the low limit has been set, the entire transaction 
may be blocked. As a second alternative, a preauthorization 
matrix may indicate whether sufficient credit remains to 65 
execute a predetermined standard deal amount in addition 
to, or instead of, a mere indication as to whether any credit 
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from a particular potential counterparty had already been 
used up. In such an alternate embodiment of the Togher et 
al. system, it might also be possible to display to each trader 
two dealable prices: one at which at least the predetermined 
standard amount is available, and a second one at which only 
a small amount may be available. Thus, individual orders are 
not independently treated, and the user may not have the 
ability to look through the bids and offers and deal at a worst 
price, if the user so chooses because of a difference in 
counterparties credit qualities. 

In accordance with another aspect of the Togher et al. 
system, at least a first trader having an open quote that is 
displayable as the best dealable or regular dealable quote al 
any of the other trading floors is automatically alerted that 
their bid (offer) quotation is the best price available to at 
least one potential counterparty with whom mutual credit 
exists, and thus could be hit (taken) at any time. Similarly, 
at least if the quoter's bid (offer) quote is not currently the 
best with at least one trading floor but is thus subject to 
immediately being hit (taken) by a trader at that trading 
floor, then the quoter is preferably also alerted if his/her 
quote is joined (i.e., equal to in price, but later in time) to 
such a best dealable or regular dealable price from another 
trading floor. In other words, in the Togher et al. system, the 
auto-matching process does not enable the active trader to 
select a price other than the best price to trade. This may 
force the trader to accept what the system offers, even if the 
trader would prefer a different counterparty for credit rea- 
sons. In addition, the Togher et al. system does not show the 
trader the total depth of the market, only those prices which 
are dealable, and thus, may fail to give the trader a complete 
picture of the market. The trader is also limited to the 
quantity stated. No provision is made for the modification or 
negotiation of the quantity or other terms of the trade. 

The systems described above are such that they focus on 
overnight settlement risk. These systems are apparently 
incapable of dealing with the actual credit requirements of a 
variety of different individual financial instruments 
simultaneously, or a counterparty's long-term ability to meet 
these requirements. As a result, these systems generally have 
only been deployed in the markets where settlement takes 
place in a few days of the transaction, and there are no 
continuous and ongoing credit requirements or obligations 
between the counterparties. Specifically, as a result of these 
limitations, these designs may not be able to support the 
anonymous trading of financial instruments such as interest 
rate swaps, caps and many other financial products. They 
may be unable to accommodate these more complex finan- 
cial instruments because, among other things, these systems 
apparently treat all financial instruments alike, and therefore, 
may be incapable of handling more complex financial instru- 
ments which require a determination about the financial 
strength of the opposing counterparties. Trades conducted 
with some financial instruments such as derivatives create 
multi-year financial commitments, and therefore, mere 
credit limit or credit cap systems are insufficient in measur- 
ing and managing an institution's credit risk. 

Accordingly, it is noted that no known system is designed 
to operate with derivative products such as interest rate 
swaps, caps, floors, forward rate agreements (FRA), interest 
rate basis swaps, interest rate options, foreign exchange, 
switches, or any other over the counter derivative instru- 
ments. Derivatives are considered by many to be too com- 
plex to be efficiently handled within an electronic trading 
system. Specifically, derivative products are typically define 
by certain terms and conditions, and the different types of 
derivatives products are defined by different sets of terms 
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and conditions. For example, an FRA is generally defined by able to identify which orders they arc eligible to trade based 

a start time, an end time, an over date, and a floating rate upon the coded credit preference data. The user is also 

option, while an interest rate swap is generally defined by a provided with a feature whereby the user can input an 

start time, an end time, an over date, a floating rate option, interest reset risks portfolio into the system and then view 

a frequency of the fixed coupons, a basis, and a special 5 his/her interest rate reset risk position relative to other 

nilc(s) as applicable with some currencies. Accordingly, the counterparties that have inputted their respective interest 

variances in the specific information necessary to adequately ra A e reset risks portfolios in order to determine possible 

define the different derivative products has apparently been oflfeetUng positions lTie user is also provided with a facility 

a deterrence to the development of an electronic derivatives for P lacin & orders for various financial instruments via an 

auction process whereby the system automatically matches 

s y all orders and determines the prices and quantities executed 

Yet another deficiency of the prior art systems is the on several guidelines including user credit prefer- 
inability to automatically determine one's position (i.e., ences. In addition, the user is provided with a switch auction 
credit risk position), and the inability to identify possible facility whereby the user can use the auction process to trade 
counterparties with offsetting positions for initiating a trans- forward rate agreement (FRA) switches with other counter- 
action. No know electronic trading system has been able to 15 parties utilizing the same credit preference screening, 
provide this information on a real-time basis. This strikes to At the central processing center, multiple server modules 
the essence of the derivatives market which is based upon operate simultaneously to perform various functions such as 
large fmancial institutions being able to manage their credit delivery of market information to the user, credit preference 
risk and market risk on a daily basis. verification of a requested trade, execution of trades, term 

Thus, a heretofore unsatisfied need exist in the industry 20 negotiation, acknowledgments, position discovery, and auc- 

for an automated system for distributing anonvmous price hon execution Tlie central processing center also includes a 

and position information via a customized financial instru- database winch provides persistent storage of information 

. i . L1 . , rr t t j-» such as historical data, instrument deiinitions, user credit 

ment symbology that enables traders to effectuate credit- c , \ . . . ' , . A . . 

. , . r i • * * l , . , preferences, user and business unit data, and historical 

based trades of complex instruments such as those in the ma rket data 

derivatives markets. At ^ trac j er workstations, multiple software modules 

SUMMARY OF THE INVENTION operate simultaneously to perform various functions at the 

front end of the system such as providing user interfaces, 

It is therefore an object of the present invention to provide performing credit preference verification, and receiving 

an improved electronic trading system for trading derivative 30 inputted user data such as trade data and credit preferences, 

fmancial instruments. The trader workstations are preferably implemented on 

It is another object to the present invention to provide - desktop computers of the users via an Internet browser 

anonymous credit-based trading of financial instruments. program, and therefore, do not require dedicated terminals 

It is another object to the present invention to provide on the desktops. The communication between the 

substantially real-time status information for selectable mar- 35 trader workstations and the central processing center is 

k els preferably based on Internet Protocol (IP), and operates over 

. . . , . , A iL t . A . . . the Internet in a secure mode. 

It is another object to the present invention to provide 

flexible control of outstanding and executed orders within an . In accordance with an embodiment of the present 

electronic trading system. invention, a system for facilitating derivative trading com- 

r . . • . n c 4 0 prises a communication network interconnecting a first user 

It is an object of the present invention to allow users of an and a secon(J ^ (Q a ^ cemer> and a 

electron* trading system to place passive orders and active market inven(ory modu , e associa f ed with f he cenlra| pro . 

cessing center that provides the first and second users with 

It is an object of the present invention to provide elec- essentially real-time order information regarding more than 

tronic means which enable traders to communicate or broad- 45 one fi nanc ial instrument, wherein the order information 

cast interest in a specific fmancial instrument anonymously inc i udes requests to buy financial instruments and requests 

to other traders who may respond with a request to trade. to ^ n financial instruments. In addition, the system may 

These and other objects of the present invention are include a trader module associated with each of the first and 

provided for by systems, methods, and computer program second users for receiving the real-time order information 

products that provide for electronic trading based on the 50 from the central processing center and for presenting the 

client/server model, including a central processing center real-time order information to the first or second users 

(i.e., server) having multiple server modules and a plurality according to respective user customized profiles. The system 

of individual trader workstations (i.e., clients), all of which m ay further include a credit preference module associated 

are operationally interconnected, preferably via an Internet- with each of the first or second users, wherein the credit 

protocol network. Because of the open architecture of the 55 preference modules indicate the trade eligibility of the 

system, it is possible that the system may run within the respective first and second users for each request to buy or 

context of an Internet browser on a user's existing desktop sell. In addition, the system may comprise an execution 

computer. At the user's workstation, the user may select module associated with the central processing center that 

from a variety of different interfaces that enable the user to processes a trade initiated by one of either the first or second 

follow markets, enter and execute trades, and monitor out- go users which desires to trade on an order posted in the order 

standing and historical orders and executions. Thus, the user information by the other of the first and second users. In 

is provided an in-depth view of the market and essentially essence, the execution module processes the term negotia- 

complete control over the order load process. tions and will-do-more services. In addition, the system may 

The market information provided to the user is coded with comprise a settlement module associated with the central 

credit preference data generated by referencing the complex 65 processing center for processing transactions and generating 

credit preferences inputted by each user regarding all pos- confirmation notices, which are submitted to both parties, 

sible counterparties. Thus, potential counterparties are then The settlement module also calculates the commission fees. 
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The credit preference module described above may deter- 
mine the trade eligibility based on credit preferences of both 
the first and second users. This system may further include 
a switch module that receives interest rate swap positions 
from the first and second users, and determines relative 
position information for the first and second users. 

In accordance with another embodiment of the present 
invention, a system for facilitating derivative trading, 
wherein the system includes a plurality of interconnected 
user nodes configured to exchange order information via a 
central processing center. The central processing center may 
comprise a first user node including a trader module that 
receives real-time order information and presents the real- 
time order information to a user according to the customized 
profiles defined by a first user, a credit preference module 
that includes credit preference data inputted by the first user 
for use in determining trade eligibility of trades proposed in 
the real-time order information with a second user, and an 
interface to a communications network that interconnects 
the plurality of user nodes. Each user node may further 
include a switch module that receives interest rate swap 
positions from the first user and the second user, and that 
determines relative position information for the first user. 

In accordance with yet another embodiment of the present 
invention, a system for facilitating derivative trading, 
wherein such system includes a plurality of interconnected 
first and second users that exchange order information, and 
wherein each of the first and second users are connected to 
a central processing center. The central processing center 
may comprise a group server that provides the first and 
second users with essentially real-time order information 
regarding more than one financial instrument. The order 
information preferably includes requests to buy financial 
instruments and requests to sell financial instruments. The 
central processing center may further comprise an execution 
module that can process a trade initiated by one of either the 
first and second users which desires to trade on an order 
proposed in the order information by the other of the first 
and second users. This central processing center may further 
include an interface to a communications network that 
interconnects the plurality of first and second users to the 
central processing center. 

Other features and advantages of the present invention 
will become apparent to one that is skilled in the art upon 
examination of the following drawings and detailed descrip- 
tion. It is intended that all such additional features and 
advantages be included herein within the scope of the 
present invention, as defined in the appended claims. 
Further, it will be appreciated by those of skill in the art that 
the above -described systems of the present invention may be 
provided as methods or computer readable program means. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The file of this patent contains at least one drawing 
executed in color. Copies of this patent with color drawings 
will be provided by the Patent and Trademark Office upon 
request and payment of the necessary fee. 

FIG. 1 is a schematic diagram of a computer network 
implementing an electronic trading system in accordance 
with an embodiment of the present invention. 

FIG. 2 is a block diagram illustrating the architecture and 
functionality of a central processing center in accordance 
with an embodiment of the present invention. 

FIG. 3 is a block diagram illustrating the architecture and 
functionality of a trader system in accordance with an 
embodiment of the present invention. 
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FIG. 4 is a block diagram illustrating the architecture and 
functionality of a business unit proxy in accordance with an 
embodiment of the present invention. 

FIG. 5 is an example of a command center interface. 
5 FIGS. 6A-6B are examples of different tabbed partitions 
of a user preference interface. 

FIG. 7 is an example of a credit preference setting 
interface. 

10 FIGS. 8 A and SB are examples of different tabbed parti- 
tions of a modify credit groups interface. 

FIGS. 9A and 9B are examples of the new binary interface 
and complex preference interface respectively, which are 
accessible from the credit preference setting interface. 

15 FIG. 10 is an example of a business unit information 
interface. 

FIG. 11 is an illustration of the.credit preference logic of 
an embodiment of the present invention. 
20 FIG. 12 is an example of a market entry interface. 

FIG. 13 is an example of a symbol definition interface. 
FIG. 14A is an example of an passive order interface. 
FIG. 14B is an example of an hit order interface. 
FIG. 15 is an example of a market detail interface. 

25 

FIG. 16 is an example of an outstanding order blotter 
interface. 

FIG. 17 is an example of a client monitor interface. 
FIG. 18 is an example of a execution notification and 
30 quantity negotiation interface. 

FIG. 19 is an example of a term negotiation interface. 
FIG. 20 is an example of a user position portfolio inter- 
face. 

35 FIG. 21 is an example of a switch interface. 

FIGS. 22 A and 22B are examples of an auction interface 
and a switch auction interface, respectively. 

FIG. 23 is an example of a main screen interface in 
accordance with an embodiment of the present invention, 
40 FIG. 24 is a flowchart of the credit preference feature in 
accordance with an embodiment of the present invention. 

FIG. 25 is a flowchart of the subject based addressing 
feature in accordance with an embodiment of the present 
invention. 

45 

FIG. 26 is a flowchart of the execution of a trade in 
accordance with the embodiment of the present invention. 

FIGS. 27 A and 27B are flowcharts of a trade execution 
from the perspective of the user posting the order and the 
5 o user acting on the order, respectively, and in accordance with 
an embodiment of the present invention. 

FIG. 28 is a flowchart of the position discovery feature in 
accordance with an embodiment of the present invention. 

FIG. 29 is a flowchart of the auction feature in accordance 
55 with an embodiment of the present invention. 

FIG. 30 is a detailed flowchart of the auction feature in 
accordance with an embodiment of the present invention. 

FIG. 31 is a flowchart of the calculation of the average 
6Q auction price in accordance with an embodiment of the 
present invention. 

FIG. 32 is a flowchart of the matching performed in an 
auction in accordance with an embodiment of the present 
invention. 

65 FIG. 33 is a flowchart of the validation of a resulting order 
in an auction in accordance with an embodiment of the 
present invention. 
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FIG. 34 is a process flow diagram illustrating operations 
and functionality of the central processing center in accor- 
dance with an embodiment of the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The present invention now will be described more fully 
hereinafter with reference to the accompanying drawings, in 
which preferred embodiments of the invention are shown. 
This invention may, however, be embodied in many different 
forms and should not be construed as limited to the embodi- 
ments set forth herein; rather, these embodiments are pro- 
vided so that this disclosure will be thorough and complete, 
and will fully convey the scope of the invention to those 
skilled in the art. Like numbers refer to like elements 
throughout. 

I. Introduction 

The following description is of a best-contemplated mode 
of carrying out the present invention. The systems, methods, 
and computer program products of the present invention 
have practical application in anonymously trading a very 
broad cross-section of credit-sensitive, bilateral financial 
instruments. However, a particular application of the present 
invention described hereinafter is directed to the use of the 
present invention for trading financial instruments in the 
derivatives market. The scope of the present invention 
should not be limited to that described hereinafter, but 
should be determined by referencing the appended claims. 

The present invention provides for a standardized contract 
definition, and means for matching complex credit prefer- 
ences of each counterparty before a trade is executed. 
Therefore, potential counterparty users are able to identify 
bids and offers that they are eligible to trade based on credit 
preference information provided before initiating a trade. 
The present invention also permits users to place passive 
orders (bids or offers on the various financial products for 
other counterparties to actively choose from to hit (bids) or 
lift (offers), without the posting user doing anything further) 
or active orders (where the viewing user actively initiates the 
trade by selecting passive bids or offers which are already in 
the system). This gives a user maximum control over the 
order flow process. For instance, there may be a situation 
whereby the bids in a particular market are higher than the 
offers, but no trading is taking place. This situation may 
occur when the credit quality of the best offer (which in this 
case would be below the bid) would not be good enough for 
a bidder to be willing to enter into a transaction with that 
counterparty. This is a significant difference from the prior 
art systems in which orders are automatically matched if the 
prices are equal because such prior art systems typically 
limited the user's control over the order flow. 

The present invention also provides fmancial markets 
with electronic trading systems and methods for identifying 
possible counterparties and executing trades for forward rate 
agreement (FRA) switches and other financial products. The 
present invention further provides the ability for the users to 
place orders for various financial instruments via an auction 
process that can be one-to-many or many-to-many, whereby 
the system automatically matches all orders and determines 
the prices and quantities executed on the basis of several 
guidelines or parameters. A further feature of the present 
invention is an auction trading that is available to users, 
whereby users can use an auction process to trade FRA 
switches with the other counterparties. This form of auction 
is referred to hereinafter as a switch auction. In the auctions, 
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the price is preferably prc-determincd by the system prior to 
the auction taking place. ITie prices determined by the 
system arc referred to hereafter as the fair price. 

The systems and methods of the present invention are 
5 designed to reflect the fact that financial institutions operate 
under many different structures. In order to accomplish this, 
the following concepts/defmitions are provided: 
Legal Entity (LE): 

This is the incorporated entity in which contracts are 
10 negotiated on behalf of by users (traders) of the 

system. 
Business Unit (BU): 

This is a grouping of individual users within a Legal 
15 Entity that act together and share attributes such as 

LE, manager, address, settlement information, credit 
preferences (see below), etc. 
Risk Equivalent (RQ): 

This is the unique measure of Risk associated with 
20 fmancial contracts such that contracts with different 

attributes can be compared on a like basis for credit 
risk purposes. 
Credit Preferences (CP): 

This is the model which allows the system to handle 
25 different measures of risk equivalent used by differ- 

ent institutions and different fmancial contracts, all 
with different internal structures. 
Classes of Financial Instruments (CL): 

These are collections of financial contracts which share 
30 similar attributes. 

Credit Groups (CG): 

A method to allocate credit preferences across classes 
of fmancial contracts. 
35 User Preferences (UP): 

A method to allow institutions or users to control or 
manage access to the functions within the system. 
Filters (FI): 

These allow users to limit the messages (i.e., request for 
40 price or request for switch they receive or view. 

Symbology (SY): 

This enables users to quickly and easily reference 
financial contracts within the system in a systematic 
manner. 
45 Term Negotiation (TN): 

This is a method which allows users to negotiate 
non-commercial terms of contract subsequently to a 
trade. For example, the exchange of bonds relating to 
a spread trade. 
50 Credit Over-Ride Process: 

This process enables a user to disclose his/her identity 
to a counterparty to see if they will accept a trade 
with him/her even though they initially refused him 
due to credit issues. 
Comprehensive Confirmations: 

This is a confirmation lay-out in order to fully defme 
bilateral contracts across any classes of fmancial 
instruments. 
60 Request For (RF) 

This is a method to broadcast to the other users (subject 
to their FI) an interest in a price or market. 

II. System Architecture 

65 As will be appreciated by one of ordinary skill in the art, 
the present invention may be embodied as a method, a data 
processing system, or a computer program product. 
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Accordingly, the present invention may take the form of an 
entirely hardware embodiment, an entirely software embodi- 
ment or an embodiment combining software and hardware 
aspects. Furthermore, the present invention may take the 
form of a computer program product on a computer- readable 5 
storage medium having computer-readable program code 
means embodied in the storage medium. Any suitable com- 
puter readable storage medium may be utilized including 
hard disks, CD-ROMs, optical storage devices, or magnetic 
storage devices. 10 

The present invention is described below with reference 
to block diagrams and flowchart illustrations of methods, 
apparatus (i.e., systems) and computer program products 
according to an embodiment of the invention. It will be 
understood that each block of the block diagrams and 15 
flowchart illustrations, and combinations of blocks in the 
block diagrams and flowchart illustrations, respectively, can 
be implemented by computer program instructions. These 
computer program instructions may be loaded onto a general 
purpose computer, special purpose computer, or other pro- 20 
grammable data processing apparatus to produce a machine, 
such that the instructions which execute on the computer or 
other programmable data processing apparatus create means 
for implementing the functions specified in the flowchart 
block or blocks. 25 

These computer program instructions may also be stored 
in a computer-readable memory that can direct a computer 
or other programmable data processing apparatus to function 
in a particular manner, such that the instructions stored in the 
computer-readable memory produce an article of manufac- 30 
ture including instruction means which implement the func- 
tion specified in the flowchart block or blocks. The computer 
program instructions may also be loaded onto a computer or 
other programmable data processing apparatus to cause a 
series of operational steps to be performed on the computer 35 
or other programmable apparatus to produce a computer 
implemented process such that the instructions which 
execute on the computer or other programmable apparatus 
provide steps for implementing the functions specified in the 
flowchart block or blocks. 40 

Accordingly, blocks of the block diagrams and flowchart 
illustrations support combinations of means for performing 
the specified functions, combinations of steps for perform- 
ing the specified functions and program instruction means 45 
for performing the specified functions. It will also be under- 
stood that each block of the block diagrams and flowchart 
illustrations, and combinations of blocks in the block dia- 
grams and flowchart illustrations, can be implemented by 
special purpose hardware -based computer systems which 5Q 
perform the specified functions or steps, or combinations of 
special purpose hardware and computer instructions. 

A trading system in accordance with the present invention 
is an electronic brokerage system which may use Internet 
protocol-based communications networks for facilitating the 55 
trading (i.e., buying and selling) of financial derivatives by 
users, each of which is associated with the user's own 
desktop computer system (trader system) located on the 
trading floor of a financial institution (client site), as 
described below. At the user's desktop computer system, the 60 
present invention is preferably implemented by a Java-based 
software program, though other suitable program languages 
can be utilized such as dynamic hypertext markup language 
(DHTML), C+ or C++. 

As shown in FIG. 1, a trading system 10 in accordance 65 
with the present invention comprises a central processing 
center 12 which is in communication with the client sites 14 
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via one or more of a variety of Internet protocol based 
networks 16. By way of illustration, a private extranet, a 
public Internet, and a third party extranet are show, though 
it will be recognized by those skilled in the art that other 
networks such as the Public Switch Telephone Network 
(PSTN) may be implemented as a network 16. Further, by 
having multiple networks 16 available, the user is provided 
redundancy in case one network experiences a service 
interruption, and the user is able to choose between the 
several networks 16 for primary access based on factors 
such as toll charges or bandwidth. 

Each client site 14 includes one or more business unit 
servers 18 which, among other things, can store copies of the 
Java applets which can be utilized to implement the present 
invention. The business unit servers 18 may also perform 
encryption/decryption functions for messages that are 
received and sent over the networks 16. The business unit 
servers 18 are preferably connected to the client sites 14 
internal data network. Thus, one or more trader workstations 
20 may be connected to a business unit server 18 of a client 
site 14. Accordingly, a user's own desktop computer which 
is connected to the client's internal data network may 
function as a trader workstation 20 and run the Java-based 
software of the present invention to enable interaction with 
other trader workstations 20 via the central processing center 
12. 

With reference to FIG. 2, illustrated is the central pro- 
cessing center 12 which includes a trade mechanism 30, a 
group server mechanism 32, auction mechanism 34, and a 
switch mechanism 35, all in accordance with the present 
invention. The trade mechanism 30 includes several mod- 
ules including a market inventory module 38, an execution 
module 40, and a settlement module 42. The market inven- 
tory module 38 holds the passive orders for each market and 
broadcast the same to the trader workstations 20 when new 
orders are received, validates any proposed trade, performs 
a second and final credit preference check that cannot be 
performed at the trader workstation 20, validates that both 
traders are still on-line (i.e., active), executes the trade, and 
sends out a status update to the traders. The execution 
module 40 receives the executed trade and proposes a trade 
for a greater quantity if applicable (referred to as the 
will-do-more feature), and processes term negotiation if 
applicable. The settlement module 42 calculates the appro- 
priate commission, generates the confirmation, and sends the 
confirmation to the two parties. 

The group server mechanism 32 interfaces the trader 
module 30 with the trader workstations 20. The central 
processing center 12 may include a plurality of group server 
mechanisms 32, each of which preferably serves a subset of 
the users (i.e., trader workstations) of system 10, though the 
system 10 may be implemented with only one group server 
mechanism 32. The group server mechanism 32 monitors 
the connection of each trader workstation 20 so that log-in 
and log-out times and usage can be monitored. The group 
server mechanism 32 also caches market information being 
viewed at each trader workstation 20 and creates an order 
identification code that uniquely identifies that order. The 
credit preference information of all users is cached in by the 
group server mechanism 32 for delivery to each trader 
workstations 20 when the associated user logs in. Any 
changes in the credit preference setting by a trader are 
detected and forwarded to the trader workstations 20 of the 
other users. 

The switch mechanism 35 is configured to receive a 
portfolio of interest reset risk for a plurality of users and 
provide the users with an anonymous view at their relative 
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position to other possible counterparties and available trades 
that may offset the user's interest rate reset risk. The auction 
mechanism 34 performs a switch auction function whereby 
orders or FRA's arc received from the users and anony- 
mously matched based on an algorithm that takes user credit 5 
preferences into consideration. 

The trader mechanism 30, group server mechanism 32, 
auction mechanism 34, and switch mechanism 35 may be 
collectively implemented as market module 44. 

The central processing center 12 includes a processor 50 10 
that communicates with the other elements within the central 
processing center 12 via a system interface 52. An input 
devise 54, for example a keyboard or a pointing device, is 
used to input data from a user, and a screen display device 
56, for example, a monitor, is used to output data to the user. 
A memory 58 within a central processing center 12 includes 
the market module 44 and a conventional operating system 
60 which communicates with the market module 44 and 
enables execution of the market module 44 (including the 
trade mechanism 30, group server mechanism 32, and 
auction mechanism 34) by processor 50. An external com- 20 
munication line 62 is provided to interface the central 
processing center 12 with other computer systems or 
computer-based devices such as networks 16. Lastly, a hard 
disk 64 may be provided as a persistence memory device, as 
well known to the industry. Preferably a relational database 25 
66 resides on the hard disk 64 for maintaining information 
such as current state information for each trade workstation 
20, user and business unit data, financial instrument 
definitions, order states, transaction states, confirmation 
states, historical confirmation and transaction data, credit 30 
preferences of all business units, and historical market data. 
Preferably, the relational database 66 is based on structured 
query language (SQL) management system, as well known 
in the industry. 

With reference now to FIG. 3, illustrated is an embodi- 35 
ment of the trader workstations 20 which includes a trader 
module 70 in accordance with the present invention. The 
trader module 70 may be implemented as a component of a 
Java -capable Internet browser program 72, such as Netscape 
Communicator® (Netscape Communication Company) or 40 
Microsoft® Internet Explorer (Microsoft Corporation) ver- 
sion 3.0 or higher. Thus, in a preferred embodiment, the 
trader module 70 is a Java-based program that is down- 
loaded as Java applets for each session and implemented by 
a Java virtual machine (JVM) 73 within the Internet browser 45 
72. r Itie JVM 73 of the Internet browser program 72 may be 
a stand alone software application, a plug-in application, or 
a helper application, all of which is well known in the art. 
The trader module 70 includes a market interface module 74, 
a credit preference module 76, a symbol module 78, switch 50 
module 80, and an auction module 81. The market interface 
module 74 comprises one or more user interfaces for pre- 
senting information to the user. In the context of the present 
embodiment, a user interface is provided as a window within 
the context of the Internet browser program 72. However, a 55 
user interface in accordance with the present invention may 
take many forms such as a three dimensional virtual reality 
world based on virtual reality modeling language (VRML), 
an audio receiver/transmitter, or any other suitable form of 
interface between the user and trader workstations 20, In a 60 
preferred embodiment, the market interface module 74 com- 
prises a control center interface, market entry interface, 
market detail interface, switch interface, and auction 
interface, all of which are described in more detail herein- 
after. 65 

The credit preference module 76 receives the stored credit 
preferences inputted by the user and stored at group server 



mechanism 32. The stored credit preferences include pref- ' 
erences directed to the other business unit's legal entities, 
and the preferences inputted by the other users directed 
toward the business unit's legal entity of the subject user. As 
mentioned above, the credit preference information, is pref- 
erably stored in the database 66 (FIG. 2). The credit pref- 
erence module 76 may encode the order information being 
presented to the user with the credit preferences of the user 
and the credit preferences of counterparty that posted the 
order. The credit preference module 76 also performs a 
credit preference check for each order when a trade is 
initiated. Because of the potential complexity associated 
with the different types of credit methods offered by the 
present invention, portions of the credit check process may 
be performed by the market inventory module 38 of the 
central processing center 12. The credit preference module 
76 at each trader workstation 20 comprises a simplified 
matrix of yes's and no's, and associated maturities. If the 
business unit has selected an even more complex method 
(i.e., complex), a unit (such as a risk quotient, i.e., RQ) by 
maturity is also required. The trader workstation 20 will 
therefore not be able to determine whether the full quantity 
can be traded. Thus, the market inventory module 38 repeats 
the credit check to ensure the very latest credit preferences 
arc used (in case of any latency in updating the credit 
preferences at the trader workstations 20) and to complete 
any complex credit preference check for quantity. 

'llie symbol module 78 stores the symbol definitions 
utilized for the subject-based addressing of the different 
financial instruments traded in the system 10. The symbol 
module 78 also provides means for defining new symbols 
for use with the system 10. The switch module 80 is 
configured to receive interest rate reset risk portfolios from 
the user which are sent to the switch mechanism 35 at the 
central processing center 12. The relative position informa- 
tion generated by the switch mechanism 35 is returned to the 
switch module 80 which presents the position information to 
the user via the market interface module 74. The auction 
module 81 is configured to receive multiple or batch orders 
on a single instrument at different price levels, and in case 
of a switch auction, to receive a interest rate reset risk 
portfolio from the user. The inputted orders or portfolio is 
sent to the auction server 34 at the central processing center 
12 where the auction or switch auction, respectively, is 
performed. The resulting matches are returned to the auction 
module 81 which presents the results to the user via the 
market interface module 74. 

The trader workstations 20 includes a processor 82 that 
communicates with other elements within the trader via a 
system interface 84. An input device 86, for example, a 
keyboard or pointing device, is used to input data from the 
user, and a screen display device 88, for example, a monitor 
is used to output data to the user. A memory 90 within the 
trader workstations 20 includes the Internet browser pro- 
gram 72 (and thus, the trader module 70) and a conventional 
operating system 94 which communicates with the Internet 
browser program 72 and enables execution of the Internet 
browser program 72 (and thus, the trader module 70) by 
processor 82. It is noted, however, that the trader module is 
preferably implemented as a Java-based program that is 
downloaded into memory 90 for the execution during a 
single session, and the trader workstations 20 will not 
persistently store the trader module 70. Further, as a Java - 
based program, the trader module 70 will be executed on a 
JVM 73 which is a component of the Internet browser 
program 72. 

An external communication link 96 is provided to inter- 
face the trader workstations 20 with other computer systems 
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or computer-based devices such as respective business unit 
servers 18. Lastly, a hard disk 98 may be provided as a 
persistent memory device, as well known in the industry. It 
is noted that the trader workstation 20 may comprise a 
desktop computer system as previously mentioned, or 5 
alternatively, the trader workstation 20 may comprise a 
portable computing device such as a notebook computer, 
handheld PC, personal digital assistant (PDA) or any other 
suitable device capable of running an Internet browser 
program and creating a communication link for interfacing 
with a network. 

Therefore, a user of the system 10 is not necessarily tied 
to a specific hardwired terminal, but has a virtual terminal 
that goes with the user wherever the user has access to a Java 
capable browser and Internet access. The trader module 70 i5 
may be implemented as an independent program capable of 
establishing a communication link to the central processing 
center 12 via the Internet, a local area network (LAN), or a 
wide area network (WAN). Thus, the user can even have 
access to the system 10 via direct modem dial-in to the 20 
central processing center 12 over the public switched tele- 
phone network (PSTN) or Internet. 

With reference now to FIG. 4, illustrated is an embodi- 
ment of a business unit server 18 which includes a proxy 
agent 110 in accordance with the present invention. The 2 5 
proxy agent 110 may perform numerous functions including 
decoding and encoding encrypted messages sent and 
received over networks 16. The proxy agent 110 manages 
traffic to and from the trader workstations 20, and may 
provide other features such as document caching and net- 30 
work access control. The proxy agent 110 may improve 
performance by storing and supplying frequently requested 
data to the trader workstations 20, or by filtering and/or 
discarding information from the networks 16. Preferably, 
proxy agent 110 resides on a business unit server 18 which 35 
is part of the respective client sites 14 internal data networks. 
However, the system 10 of the present invention may be 
implemented without business unit servers 18, whereby the 
functionality of the proxy agent 110 may be incorporated 
into the trader module 70 of the respective trader worksta- 40 
tion 20; such functionality including decoding and encoding 
encrypted messages, and network management. 

The business unit server 18 includes a processor 112 that 
communicates with the other elements within the business 
unit server 18 via a system interface 114. An input device 45 
116, for example, a keyboard or pointing device, is used to 
input data from a user, and a screen display device 118, for 
example, a monitor, is used to output data to the user. A 
memory 120 within the business unit server 18 includes the 
proxy agent 110 and a conventional operating systems 122 50 
which communicates with the proxy agent 110 and enables 
execution of the proxy agent 110 by processor 112. An 
external communication link 124 is provided to interface the 
business unit server 18 with other computer systems or 
computer/based machines such as networks 16 and trader 55 
workstations 20. Lastly, a hard disk 126 may be provided as 
a persistence memory device, as is well known in the 
industry. Particularly, the hard disk 126 may include trader 
data profiles 128 for each of the different trader workstations 
20 associated with the business unit server 18. Alternatively, 60 
the trader data may be stored at the central processing center 
12 so that the trader does not need to re-build his/her screens 
each time he/she longs onto the system 10. 

Thus, each trader workstations 20 at a client site 14 is able 
to access the system 10 through the Internet browser pro- 65 
gram 72 operating on the user's desktop computer. In order 
to access the system 10, the user may run Java-based applets 
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on the desktop computer in the Internet browser program 72 
which may be up-loaded to the desktop computer system by 
one of three means: 1) accessing them from the hard disk of 
the desktop computer 2) downloading them across the 
network from a server on the internal data network of the 
client site, or 3) by downloading them directly from the 
central processing center. Once the applets arc loaded and 
running in the desktop computer of the user, the user is then 
able to access the system 10 and interact with other trader 
workstations 20 and engage in trading activities. In addition 
to traders at the client sites, a preferred embodiment of the 
present invention also enables non-trader users at the client 
sites 14, such as credit officers and other interested/relevant 
staff, to have access to the invention in the same manner as 
the users in order to monitor the trading activities, perform 
credit control or any other functions. 

III. System Features 

The following are features of the present invention which 
provide particular functionalities and utilities. These fea- 
tures include interfaces such as a command center interface, 
a market entry interface, a market details interface, an 
outstanding order interface, an historical order interface, and 
functions such as symbology, credit preference checking, 
term negotiation, automatic notification, interest rate reset 
risk switches, and order auction. 

When beginning a session on the system 10, a user at a 
trader workstation 20 launches the Internet browser program 
72 and goes to a particular address that connects the trader 
workstation 20 to the central processing center 12. This is 
preferably achieved by typing a known URL (Universal 
Resource Locator) in an address field of the Internet browser 
program 72. At the URL entered, the user will be presented 
with a log-on screen which preferably requires the user to 
input a user name and password for identification, verifica- 
tion and security reasons. After the user logs on, the user will 
download (preferably from proxy agent 110) the Java 
applets which will run locally on the desktop computer 
comprising the trader workstation 20. Alternatively, the user 
may launch a local or network application that runs locally 
or on an attached server. The application will enable a 
connection to system 10 over network 16, much the same as 
numerous dial-up services such as AOL. In addition, other 
information such as user defined preferences which are 
based on the trader's profile will be downloaded to the trader 
workstation 20. This may include information on what the 
user is allowed to trade, what markets the user is interested 
in monitoring, and other user specific information that was 
previously been defined by the user or another individual 
such a credit officer or the like. 

After the user has successfully logged on and the requisite 
Java applets have been downloaded and are running on the 
JVM 73, the user is presented with a command center 
interface 130, as illustrated in FIG. 5, via the screen display 
device 88 (FIG. 3). The command center interface 130 is the 
front end of the user interface which provides access to all 
other features of the present invention, as described below. 
In an embodiment of the command center interface 130, the 
command center interface 130 is a pop-up window rendered 
on the screen display device 88. Note, however, when the 
command center interface is running, the user may be able 
to iconize (i.e., minimize) the Internet browser program 72 
window, as may be desirable when the user no longer needs 
to view the Internet browser program 72. 

From the command center interface 130, a user can access 
the features of the system 10 which enable the user to 
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monitor and control their trading in the system 10. 
Specifically, from the command center interface 130 the user 
can access the following areas of functionality as menu 
options on the tool bar 132: a market entry interface 
(described below with reference to FIG. 12), a credit settings 5 
interface (described below with reference to FIG. 10), a> 
switch engine interface (described below with reference to 
FIG. 22), auction interface (See FIG. 13), tools, a user 
preference interface (described below with reference to 
FIGS. 6 A and 6B), an historical order blotter interface JQ 
(described below with reference to FIG. 17), an outstanding 
order blotter interface (described below with reference to 
FIG. 16), links to external applications such as Market- 
Sheet™ (a trademark of TIB CO, Inc.) (referred to herein as 
the quote screen and graph screen for illustrative purposes), 15 
a logout interface (provides secure exit from the system 10), 
and a help interface where detailed on-line help is provided. 
The menu options that appear in the tool bar 132 are 
preferably customizable to a user, and those described are 
merely illustrative. 20 

In addition, the command center interface 130 provides a 
message display window 134 for displaying real-time mes- 
sages. These messages include system information, market 
information, requests-for-prices (RFPs), requests-for-switch 
(RFS) or online chat sessions with the users of the system 25 
10. Below the message display window 134, the command 
center interface 130 displays the user's name 136, the user's 
default currency 138, the user's business unit 140, and other 
relevant information. The background color of the message 
display window preferably changes if the connection to the 30 
central processing center 12 is lost for any reason. 

A user preferences interface 148, which is accessible from 
the command center interface 130 via the tool bar 132, 
provides a user with user preference features, such as those 
illustrated in FIGS. 6A and 6B. In FIG. 6A, a Derv Filters 35 
tab enables a user to set request -for-price (RFP) filters for 
viewing different derivative instruments based on the type 
(i.e., class) of derivative instruments and the currency. The 
user may also select the manner of presentation (i.e., high- 
lighted or not). From the Derv Filters tab, the user is able to 40 
add and remove the derivative instruments from the user's 
viewing list, that is, the list of instrument that will appear on 
the message display window 134 of the command center 
interface 130 In FIG. 6B, an Environment tab enables a user 
to select viewing options to change the appearance of the 45 
display. In regard to the color coding display option, it is 
noted that the user can select not to have order information 
color coded by selecting color blind user. In such a case, 
other means of notation are utilized such as markings or 
symbols, as may be desirable if the user is color blind or 50 
using a monochrome screen display device 88. User defaults 
for Credit Group, Instrument Class and SWF Currency may 
also be selected via the environment tab. 

At this point, it is worth noting several functionalities that 
are integral to the operation of the present invention. In 55 
particular, it was recognized that in order to achieve an 
electronic trading system for a wide range of fimancial 
contracts, a solution had to be developed to solve two very 
critical problems: (1) how to identify fmancial contracts, and 
(2) how to allow institutions to describe their credit prefer- 60 
ences or relationships for these instruments. As solutions to 
these problems, the present invention provides the symbol- 
ogy and credit preference features described below. 

The symbology of the present invention was developed 
because, unlike foreign currency trading, where the fmancial 65 
instruments are simple, verbally explaining all the terms and 
conditions of a derivative transactions can be a laboriously 
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complex process which can take a relatively long period of 
time to explain. Furthermore, most derivative transactions 
are specifically customized to fit a particular need. With 
derivatives, as compared to stocks, bonds or other financial 
instruments, there are typically many more parameters, such 
as the maturity, fixed interest rate, floating interest rate, 
currency, floating rate index, and calculation rates, which are 
important and arc preferably defined. This complexity has 
allegedly been one of major inhibitors to the development 
and implementation of an efficient inter-dealer electronic 
trading system for over-the-counter (OTC) derivatives. 

The symbology will, among other things, ensure that the 
symbols are intuitive to the trading community, allow new 
symbols to be system generated when new instruments are 
introduced, and enable detailed confirmations to be pre- 
pared. These goals are generally accomplished by system- 
atically dividing the parameters, terms, and conditions defin- 
ing these derivatives instruments into a four-part subject 
code, 'ttiis four-part subject code enables the users to ref- 
erence these instruments via a form known as subject-based 
addressing. The four-part subject code is divided as follows: 
SOURCE.CLASS.SYMBOL.CURRENCY. Each field of 
the four-part subject code is defined below. 

The source field of the symbology identifies the source of 
the information. In most cases, this will be the code DNI 
(i.e., Derivatives Net, Inc.), the assignee of the present 
invention. If the symbol is used within the system 10, then 
the source field of the symbology will be assumed to be DNI, 
and will be omitted. If the symbol is used in a larger context, 
then the source will be identified. If, for example trade data 
were to be distributed and accessed via a third-party data 
distribution system such as the type operated by Reuters, 
Inc., then the source field of the subject code would be used. 

The class field identifies the principal product class into 
which the financial instrument falls. The class parameter is 
designed to group financial contracts together which share 
similar attributes. For purposes of the present disclosure, 
eleven classes of instruments, each with distinct character- 
istics covering forward rate agreements, interest rate swaps, 
interest rate basis swaps, interest rate options, foreign 
exchange and switches, will be covered. It is noted that a 
switch is the simultaneous purchase and sale of two instru- 
ments within the same class. The following is a listing of the 
eleven classes and the associated abbreviation for each: 

FRA — forward rate agreement 

SWP — interest rate swap 

CAP — interest rate option (cap or floor) 

SOP — interest rate option (swaption) 

IBS — interest rate basis swap (floating vs. floating swap) 

SPT — foreign exchange spot 

FWD — foreign exchange outright forward 

FXS — foreign exchange swap 

SWF— FRA switch 

SWT — switch any other pair of instruments in the same 
class 

CBS — currency basis swap 

The symbol field is the principal code used to defme each 
instrument. The symbol field is the most explicit field of the 
subject code. This component of the naming convention 
enables the underlying structure of the derivative instrument 
to be defined. A simple description (e.g., 1 yrswap) could be 
used, but this does not allow new derivative instruments to 
be easily added. The legend below defmes the parameters 
for defming each of the different instruments or classes. The 
symbol relies on the definitions of the underlying 
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parameters, which will allow further break down or defini- 
tion. For example, FLO FT is a two letter code which 
describes the variable rate index to be used, and will include: 
the designated maturity, index name, source, non-business 
day convention and calculation description. The symbols of 
the present embodiment are as follows: 

FRA: [START, END, OVER, FLOPT] 

SWP: [START, END, OVER, FXDBASIS, FLOPT, SPE- 
CIAL RULE] 

CAP: [START, END, OVER, FLOPT, TYPE, STRIKE] 
SOP: [START, OVER, UNDERLYING SWAP, 

SOPTYPE, STRIKE, OPTIYPE] 
IBS: [START, END, OVER, INDEX1, INDEX2, 

ARREAR] 
SPT: [CCYl(terms), CCY2 (base)] 
FWD: [CCYl(terms), CCY2 (base), START, END, 

OVER] 

FXS: [CCYl(terms), CCY2 (base), START, END, 
OVER] 

SWF: [FLOPT, DAY1, DAY2] 
SWT: [ASSET1, ASSET 2, CLASS] 
CBS: [START, END, OVER, INDEX1/CCY1, INDEX2/ 
CCY2] 

The symbol fields set forth above include the following 
parameters: 

START: The START parameter is the month the contract 
commences offset from value date, i.e., 1,2,3, . . , 
13, . . . ,360. The default setting for the START is (0) 
which represents that a contract starting with the cur- 
rent month. Also, see OVER below. 

END: The END parameter is the fmal maturity from value 
date in months adjusted for the OVER, and represents 
the term, i.e., 1,2,3, . . , 13, . . . ,360. If the value date 
is 28th of November, then a contract defined as [1,4 
over the 12th] translates into a deal starting on the 12th 
of January and maturing on 12th of April. 

OVER: The OVER parameter represents a specific date in 
the appropriate month. For example, if today is the 3rd 
December (value date is the 5th of December), then a 
1*4 over the 12th would start the 12th of January, the 
first date over one month but less than two months 
beyond the spot date. This allows a contract to be 
defined with any start date between days 1-31, Note 
that this represents the actual date and not the number 
of days forward. The default setting for the OVER is 
(0), which represents spot starting. Two other param- 
eters are allowable: (I) which represents IMM 
(International Monetary Exchange) rolls (the system 10 
covers the different IMM conventions defined by the 
currency market, that is, the third Wednesday or second 
Thursday) and (E) which represents rolls over the 
month-end. 

FXD BASIS: The FXD BASIS parameter is a two-part 
code covering the frequency and the basis of the fixed 
coupons. Examples are FREQ: M~Monthly, 
QoQuarterly, S»Semi-annually, A= Annually, Z»Zero 
Coupon plus BASIS F-A/365 Fixed, B-30/360, M-A/ 
360, I=A/365 IS DA, etc. For instance, SM is semi- 
annual A/360 or semi-money]. 

FLOPT: The FLOPT parameter is a two-part code cov- 
ering the frequency and the index type of the floating 
coupons, and represents the floating rate option as 
defined by ISDA. The FLOPT parameter covers 
frequency, basis and source. 



50 



Although each currency may have a default, most indices 
will be available. FLOPT examples are L=Libor 
(TELERATE 3740/50), P-Pibor (TELERATE 20071), 
T=Tibor, C-CDOR, B-AUS Bills (REUTERS 
BBSW), FF=Fcd Funds (HI5), TBoT-bills (H15), 
PR-Primc (H15), CP=30 dav Commercial Paper, 
BE=BELO, S-STIBOR, TAMTAM, A=>AIBOR, 
D-CIBOR (REUTERS DKNK), RL=Libor from Reu- 
ters LIBO, and IL=Libor from Reuters ISDA. 

CAPTYPE: The CAPTYPE parameter includes defini- 
tions for cap (C) and the floor (F). Thus, in a preferred 
embodiment, the following code is utilized: C=Cap, 
F=Floor. 

SOFLYPE: Jlie SOPTYPE parameter includes defini- 
tions for payers (P) and receivers (R). Thus, in a 
preferred embodiment, the following code is utilized: 
P-Payers, R=Receivers, X=Call, Y=Put. 

OPTYPE: The OPTYPE parameter is the option type: 
(E)uropean, (A)merican or (M)ultiple European. 

STRIKE: The STRIKE parameter indicates the cap or 
swaption's exercise rate or price set on the option. Any 
strike defmed in the symbol as ATM (at-the-money) 
will be shown as such in this parameter. In such a case, 
the percentage or strike will be agreed through the term 
negotiated process discussed below. 

SPECIAL RULE: The SPECIAL RULE parameter is 
designed for currencies such as USD and CAD which 
are in particular markets that use few special conven- 
tions for trading. For example, semi -bond for spread 
trades and annual money for out -right swaps are widely 
used in these markets. The SPECIAL RULE parameter 
allows the system 10 to set more than one set of 
defaults for any currency. This will allow the system 10 
to know when the exchange of bonds is required 
following a transaction. The follow are the rules for the 
present embodiment: 
A — Default in all currencies 

S — USD spread trades. The default in USD is annual 
money versus 3 month LIBOR. This rule defmes, semi- 
bond spread trades where bonds are exchanged in the 
terms negotiation function described below. 

2 — CAD spread trades The default in CAD is annual 
money (A/365 fixed) versus 3 month CDOR paid 
semi-annually. This rule defmes semi-annual A/365 
fixed versus 3 month CDOR paid semi-annually 
where bonds are exchanged in the terms negotiation 
function described below. 

3 — AUD long trades. The default for AUD is a 
quarterly/quarterly structure. This applies for trades 
up to and including three years. In trades over three 
years, the convention switches to a semi/semi struc- 
ture. This rule supports a semi/semi structure. 

A — AUD spread trades. Its is conventional to trade 
swaps in the AUD market against the bond futures 
contracts with an agreement for an exchange for 
physical. 

5— GBP spread trades. The default in GBP is annual 
money (A/365 fixed) versus 6 month LBOR. Ill is 
rule defmes semi-annual A/365 fixed versus 6 month 
LIBOR where bonds are exchanged in the terms 
negotiation function described below. 
ARREAR: The ARREAR parameter defines when the 
coupon(s) on a swap is both set and paid. Most interest 
rate swaps set their floating rate coupons at the begin- 
ning of the period and pay them at the end of a coupon 
period. In an ARREAR swap, however, the coupon is 
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set and paid at the end of the period. This is commonly 
referred to as an arrears swap. The system 10 allows for 
this in the form of a basis swap. 
DAY1/2: The DAYl/2 parameter is the number of calen- 
dar days offset from today to the start of each FRA in 5 
an FRA switch (class SWF). Thus, the DAYl/2 param- 
eter represents the setting day or date. 
CCY1/2: The CCY1/2 parameter is the currency code and 
is defined by the ISO codes for foreign exchange 
instruments. 10 
UNDERLYING SWAP: The UNDERLYING SWAP 
parameter is the full symbol, alais or security ID of the 
interest rale swap that underlies an option. 
INDEX1/2: Basis Swaps are when both sides are a 15 
floating rate, and the index represents the FLOPT plus 
the currency code of each index. The first listed index 
(INDEX1) is paid by the buyer. Examples include 
1L-USD, 3L-GBP, PR-USD, etc. The second index 
(INDEX2) is received by the buyer. These are substan- 2 o 
tially identical to the codes used in the switch mecha- 
nism 35 (FIG. 2). For currency basis swaps, it is 
assumed that an exchange of principals takes place at 
the start and end on the contract. 
ASSET1/2: The class SWT is provided to allow for the 25 
trading of switches in other classes other than FRAs, 
ASSET1 and ASSET2 represent the symbol, alias or 
security I.D. of each underlying contract. Note that 
both should be provided from the same class of con- 
tracts. 30 
SETTLE: The SETTLE parameter is a flag indicating 
whether a swap ti on is cash or physical settlement. The 
default is cash (C). 
An example of an order in accordance with the symbol - 
ogy of the present invention is DNI. FRA.1,4.0,3L.USD, 35 
where DNI is the source, FRA is the class, 0.1,4.0,3L is the 
symbol and USD is the currency. In particular, the symbol 
field defines a 1 by 4 (i.e., 3 month starting in 1 month) FRA 
on a 3 month LIBOR spot starting. Note that a comma (,).is 
used in the symbol fields as a delimiter. Another example of 40 
an order in accordance with the symbology of the present 
invention is DNI.SWP.0,60,0,AB,6LA.DEM, where DNI is 
the source, SWP is the class, 0,60,0, AB,6LA is the symbol 
and DEM is the currency. In particular, the symbol field 
defmes a five year (60 month) annual bond (AB) versus a 6 45 
month UBEROR swap. 

Accordingly, the Symbology described above is designed 
to capture the parameters or commercial terms of a deriva- 
tives instrument which affect the instrument's valuation. The 
present invention provides a number of default values which 50 
are assumed at all times. For example, the following is an 
exemplary list of system default values. 

ROUNDING: The rates observed on the source page or 
document will be used unless otherwise agreed. Rates 
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should be rounded to 5 decimal places after any opera- 
tion of averaging. 

RESET DATES: This will be defmed with reference to 
payment dates. The reset dates should be offset by the 
standard number of days for the currency, for example, 
two business days for USD. 

BUSINESS CENTERS TO APPLY TO RESET DAYS: 
The business days used to defme the current offset for 
reset dates is defined by the source and not the pay- 
ments under the transaction. For example, London will 
always be used for LIBOR (the exception is for USD 
LIBOR which uses both London and New York City) 
and New York City for H.15 rates. 

INTERPOLATION: Where interpolation is required, a 
straight-line method using the reference rates on either 
side of the desired date should be used. 

CALCULATION PERIODS: First and not last conven- 
tion. Therefore, the calculation period includes the first 
payment date but excludes the next payment date. 

TERMINATION DATE: All termination dates will be 
subject to adjustment if they fall on a non-business day. 

ADJUST CALCULATION PERIOD: The number of 
days is assumed to adjust if the payment days are 
adjusted for non-business days. 

TRADE DAY: Trie trade day is defmed relative to the 
instrument and currency by the system 10, and not by 
the location of either of the parties to the transaction. 

NET PAYMENTS: Net payments will be assumed for all 
transactions completed through the system 10. 

CANADIAN DOLLAR SWAPS: The convention is to set 
quarterly and pay semi-annually using weighted aver- 
aging and compounding at the first rate. 

DATES: All dates are listed unadjusted for non -business 
days. 

Users may also want to be able to negotiate other param- 
eters which do not affect the valuation of the derivative 
instrument, but are still very important. These parameters 
are referred to hereinafter as non -commercial terms. The 
difference between commercial and non -commercial terms 
can be vary ambiguous, and therefore, some of the terms 
designated as commercial below may be designated as 
non -commercial and become default settings so as to be part 
of the symbology parameter. For purposes of illustrating the 
present invention, non -commercial terms have been given 
default values which the users can change by negotiating 
new values for these terms between themselves via the 
system 10. However, both counterparties (users) must agree 
on the new value to over-ride the system defaults. Table 1 
below provides a list of parameters that maybe negotiated, 
that is, the non-commercial terms: 



TABLE 1 



PARAMETER DESCRIPTION 



SETTING 



Legal The format of the legal agreement used 

Month-end Whether coupon payment dales roll on 

month-end dates or not 
Settle For swaptions whether the contract is 

cash or physically settled 
First Setting For swaps the first variable rate is 

normally known for spot starting 

instruments. The current setting can 



ISDA, BBA, FX 
YES, NO 

CASH, PHYSICAL 

SETTING displayed on 
market entry interface. 
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TABLE 1-continued 



PARAMETER DESCRIPTION 



SETTING 



ATM 



Spot 



Bond Exchange 



quickly become off market on days 
where the market moves substantially. 
The system will display the default at 
all time. 

For options, symbols will be set up 
where the strike Ls defined as al-the- 
money (note: pre-defined strikes will 
also be available). The actual strike 
will be negotiated immediately 
following the transaction by the two 
parties. 

For foreign exchange swaps (class 
FXS only) where the price is 
transacted in the form of points, the 
spot level to be used will be negotiated 
immediately following a transaction. 
Switches will be transacted in the form 
of the relative price between the two 
instruments being switched. The base 
rate maybe negotiated immediately 
following a transaction. 
For USD, CAD and GBP interest rate 
swaps transacted as a spread, the price 
and number of bonds will be 
negotiated immediately following the 
transaction 



The system forward rate 
wilt be available 



The system mid spot 
price will be available 



The system mid price 
will be available 



The system will list the 
benchmark bonds to be^ 
used and will calculate a 
default price and 
number according to 
market convention. 



Because the above symbols that comprise the subject- 
based addressing may be complex, users may occasionally 
desire a simpler naming convention to reference the more 
commonly traded derivative instruments. To facilitate more 
rapid referencing of an instrument by a user, the symbology 
of the present invention provides aliases. An alias is merely 
an abbreviated version of the subject-based address for the 
more commonly used terms for an instrument. The database 
66 (FIG. 2) maintains a unique security identifier (such as a 
numeric code, e.g., 111222) for each symbol which can be 
used in the system 10. Thus, the symbology of the present 
invention enable traders and other users of the system 10 to 
quickly reference a particular derivative instrument in the 
system 10 in three ways: the full symbol, the alias, and the 
identifier. 

The currency field of the symbology contains the code 
that defmes the currency of the instrument represented. In a 
preferred embodiment, the currency code is represented by 
the standard ISO currency codes, i.e., USD, DEM, IPY, 
GBP, FRF, NLG, BEF, AUD, CAD, ITL, ESP, DKK, SEK, 
EUR, etc. The default currency will be set by each user in 
each user's preferences interface 143 (see FIG. 6B). This 
will allow the currency code field of the symbology to be 
omitted much of the time. However, foreign exchange trades 
(FXS) preferably include the currency code. Further, the 
currency code represents the currency which will be indexed 
in equal amounts for both the spot and forward coupons. 

The credit preference feature of the present invention 
provides for the bilateral credit status between two entities 
to be captured, structured and used anonymously for the 
trading of a wide range of fimancial contracts. In prior art 
systems, credit information was primarily used to deal with 
settlement risk in trading spot foreign currency. In such prior 
art systems, the credit line or limit is usually expressed in 
amounts of currency which equates with the quantity or 
volume of a particular trade. As trades are executed between 
counterparties, the amount of the limit is decreased in a 
corresponding amount to the trade executed until there is 
little or no remaining credit, and then further trading is 



prevented until the trades settle or the credit limit amount is 

30 re -set. In foreign currency trading, the settlement process is 
completed in only a few days, after which both counterpar- 
ties have exchanged the currencies, and then there is no 
further credit risk between them (i.e., the trades have 
settled). This is vastly different from derivatives trading, 

35 where the amount at risk is normally not equal to the 
principal or quantity of the transaction and the obligations 
under the contract may continue into the future. Derivative 
trades can be anything from spot (the normal settlement of 
a foreign exchange contract) to thirty years into the future, 

40 Therefore, the resulting credit exposure (i.e., the value of a 
contract at a future time) is over the life of a contract of an 
unknown amount 

The credit preference feature of the present invention is 
configured to handle the significant long-term credit prob- 

45 lems inherent in over-the-counter (OTC) derivatives trans- 
actions. These long-term credit problems are further com- 
pounded by the fact that there is no standard method for 
banks to internally monitor and manage their credit risks. 
Most banks have developed their own, often proprietary, 

50 methods of monitoring and measuring the credit risk embed- 
ded in large portfolios of derivatives. Furthermore, banks 
also have different methods for dealing with the many 
different financial instruments that exist in every market, 
The credit preference feature of the present invention 

55 addresses these problems and provides a viable solution. The 
credit preference feature of the present invention achieves 
this, at least in part, by introducing a measurement unit of 
credit risk referred to as risk equivalent (RQ) which allows 
for different instruments to be compared on a like basis using 

60 a standardized measuring methodology, which together with 
the concepts of contract maturity, credit groups, classes, 
credit preferences, legal entities and business units allow the 
system 10 to offer a solution to the credit risks embedded in 
bilateral, term derivatives contracts. The present invention 

65 also provides for the designation of credit groups. A credit 
group is a grouping of classes of financial contracts that a 
business unit wishes to be treated in a like manner for credit 
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purposes. In a preferred embodiment, three default credit amount that can be lost when a counterparty defaults on its 

groups will be available: (1) Derivatives— SWP, IBS, CAP, obligation. As previously mentioned, the credit risk in a 

SOP, FR A, CBS; (2) Switches SWT, SWF; and (3) foreign derivatives transaction is relatively complex. For instance, 
exchange. Anv other combination may be set up by the , , ■ t r 

3 v 3 though derivative contracts come in many forms, the major- 

business unit, as desired, 5 .. c • j- , <■ , . 

Credit preferences are the methods or rules selected by a u y nave a fair credlt value of zero at the time the transaction 

business unit within a credit group for the system 10 to use ^ initially entered into. That is, no funds are transferred 

to screen prices (bids or offers) and trades against all other between the parties at the time the contract is created, 

legal entities. In a preferred embodiment, the following three Rather, the contract places an obligation on both over the 
credit preferences are provided, though it will be appreciated 10 term of the contract. Further, both parties are entering into a 

by those of ordinary skill in the art that other credit prefer- contract which requires them to accept a certain amount of 

ences may be utilized in accordance with the present inven- risk ^ RQ is a unit of credil risk which albws all 

tl0n ' contracts to be compared on a like basis, at virtually anv 

Method 1: Binarv (simple yes/no) — This is used where • t • t; . - r , Drk • t , amne „ n ;« ~f 1 

, ' \ a * „ J / . , t point in time. J he RQ is the credit exposure in terms 01 a 

mark-to-markct (MIM) agreements exist between the 15 nt of the principal 

counterparties. MTM are bilateral, collateral agree- y B * v 

ments which are common and reduce the credit risk ^ calculation ot RQ is based on the potential exposure 

between two parties to almost zero by the posting of averaged over a series of time points, weighed by an 

collateral against the value of a portfolio of derivatives appropriate discount factor. There are several methods of 

covered by a single ISDA (International Swap and 2 n calculating the exposure of a transaction, though the RQ is 

Derivatives Association) master agreement. calculated herein using an option pricing approach, as 

Method 2: Line Binary — takes into account the maturity described below, 

(quoted in months from trade date) of the financial For a certain partV) a transaction can be viewed as two 

opposite cash flows. Inflows arc assets, denoted by A(t), and 
Method 3: Complex— This is based on the RQ of each 25 outflows are liabilities, denoted by L(t). Therefore, the 

contract within maturity bands. The system calculates a . . ^ _ r 

_ _ _ , . • t r <■ current exposure may be expressed as tollows: 

RQ for each instrument in the form of a constant 

currency unit expressed as a percentage. Each business E(t)=max(A(t)~L(t),o) 

unit has the choice of using the system generated RQ 

unit or to provide their own. 30 
In the binary method, a business unit makes a yes or no This formula is similar to the intrinsic value of a call 
determination as to whether or not they will deal with a option. The key difference is that both A(t) and L(t) can be 
particular counterparty for a particular credit group. In this random. Thus, following the same structure by the Black- 
credit preference, the decision is binary; there is no maxi- Scholes, then: 
mum maturity limit (i.e., time limit) or quantity limit (i.e., 35 

amount) in the binary method. The binary method is the EE{t) = A<p{do - UO&dih 

broadest of the three credit preference definitions provided 

for herein. Typically, the binary method will be used to where 

refuse credit, where MTM agreements exist or where the d ^ _ cr ^^jj 

credit exposure is small (for example, in switches). 40 

In the line binary method, it is assumed that the business log f £W V + ^(0 ^ 

unit will deal with a particular counterparty for a particular rf _ v 2 

credit group. However, the line binary method adds a further a^)V Hr) 

restriction of a maximum maturity of any contract tradable. 
The added restriction is preferably expressed by the number 45 

of months into the future. The binary method is particularly wnere ^ ^ the daily volatility (in percent) that takes into 
well suited for used by institutions that are not yet using RQ accoum lnat both A(t) and ^ m random ^ maximura 
units, but which desire a method to limit potential exposure exposure estimate is based on the following equation: 
to longer dated contracts (for example, a temporary step). 

The complex method allows each business unit to exactly 50 ^ f 

stipulate the amount of new risk that they are prepared to ME(t) = A(r) - Ut) + ^X 1 ' 650 ™^--^™ - 1 

enter into with any other legal entity for each credit group by 
maturity band. The complex method enables a business unit 
to specify not only a particular maturity, but also a particular 

quantity or amount based on a measure of RQ. Further, the 55 Thus, the RQ can be expressed as: 
complex method enables the business unit to specify this for 

more than one period in time. For example, a business unit _ AEEjt) ^ 

can specify that for Bank A, they will do up to $100 million " Principal * 

out for 5 years, and then only $50 million from thereafter out 
to 10 years, and nothing thereafter. 60 

Risk is generally defmed herein as the degree of uncer- where 
taint y of future net returns. Credit risk is further defined as 
an estimate of the potential loss due to the inability of a N 
counterparty to meet its obligations. Thus, while the risk in AEE{t) = ^oHQEXEU)] 

a particular transaction depends not only on the changes in 65 f=o 
market rates and credit standing of the counterparty to the 
transaction, the credit risk or exposure is the nominal 
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where 



w(0 = - 



AO 
Z6(t) 



where 



where 6(t) is the discount factor at future time t. 
For FRA's, the following equations apply: 

AfO^discountFactor^, s) M x+(l+floatingCoupon)"discountfactor(t, 

e) 

where 

floatCoupon=l *(e-s)/floatBasis*floatRatc ) and 

L(t)=l *discountFactor(t J s)*x+(l+fbrCoupon)*discountfactor(t, c) 

fixCoupon= 1 * (e-s)/fixBasis * fix Rate , 

for t<s, x=l, and 
for l>=s, x«0. 

Then we can apply the above formula for RQ to get the 
expected exposure at time t. By choosing the time partition 
t0,tl,t2 . . . , tn and calculate the expected exposure at each 
point and use the formulae of RQ, the RQ of this FRA can 
be calculated. 

For SWAP'S, the following equations apply for any time 
(t,<t<=t i+1 ): 

A(t) = ^ JloalingCouporiij) * discount Factorit, ij) + 

j-i 

1 * discoiwtFactor[t f f„), 



10 



20 



25 



30 



35 



Ut) - £ fixedCouporitj) * discouruFactor{t, tj) + 



I *discountFaciotij > r„), 



40 



where floatingCoupon(t y ) is the floating coupon at time t ; , 
and fixedCoupon(t y ) is the fixed coupon at time t y . Then 
apply the formulae of option pricing approach, we can get 
the expected exposure at time t, by averaging the expected 
exposure with the discount factor, the RQ can be calculated. 

At this point it may be worthwhile to distinguish the credit 
preference feature of the present invention from other 
known systems. The credit preference of the present inven- 
tion does much more than merely monitor the amount 
transacted between two counterparties and then reduce the 
amount available accordingly. The prescreening performed 
by the credit preference of the present invention is used to 
prescreen possible trades based on each counterparty's 
credit preferences. The present invention does not control a 
user trading and does not directly limit the user's future 
trading based upon the user's past trading. In fact, it is quite 
possible that a new transaction may reduce the exposure 
between two legal entities. A user's business unit is respon- 
sible for monitoring the credit exposure of the business unit 
with respect to all legal entity counterparties, and for adjust- 
ing the credit preferences in the system 10 accordingly. This 
is a significant difference from prior art systems that auto- 
matically decrease the amount available to trade with 
respective counterparty as transactions are executed. The 
credit preference of the present invention represents an 
improvement over such systems because the balance of risk 
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65 



is based on the total portfolio between the two panics and 
not merely the new transactions, and the balance of risk will 
be affected by market movements, deals executed outside 
the system 10, and internal changes to the ratings. 

Credit decisions for OTC derivatives arc considered dif- 
ferent from many other financial instruments. In general, a 
credit decision for an OTC derivative is a function of, among 
other things, the composition of the user's current deriva- 
tives portfolio, the current level or prices of the fmancial 
markets, new financial transactions, and the rating or level of 
credit worthiness of each legal entity. Therefore, more 
sophisticated means such as the credit preference prescreen- 
ing of the present invention is needed to adequately measure 
and manage credit exposure in the OTC derivatives market, 
as well as with other fmancial markets. 

The present invention enables the user to set desired credit 
preferences for each legal entity via the credit preference 
interface 170, as illustrated in FIG. 7. A user can navigate to 
the credit preference interface 170 by selecting the credit 
settings button in the tool bar 132 of the command center 
interface 130 (FIG. 5). The credit preference interface 170 
enables the users to view and/or update credit preference 
settings in a clear, simple, comprehensive and intuitive 
manner. The credit preference interface 170 may be used to 
view or input/amend the business unit's credit preferences. 
The credit preference settings are preferably only viewable 
by users within a business unit, and amendable by users with 
the correct permissions, both of which may be designated by 
the financial institution or the business unit. A business unit 
may also select to inherit credit preferences from another 
business unit within its family hierarchy. 

In a preferred embodiment, the credit preference interface 
170 includes a display window 172 that displays various 
information including an alphabetical listing of all other 
legal entities (i.e., fmancial institutions) that have access to 
the system 10. Each legal entity can be expanded via an 
expand button 174 to list the settings for all the credit groups 
that the user has selected to trade within that legal entity, as 
shown for the Merrill Lynch entry. For those legal entities 
that are not expanded in window 172, the settings displayed 
are for a designated default credit group 176. The user can 
modify the displayed credit groups by selecting the Modify 
Credit Groups button 178 which launches the modify credit 
group interface 180, as illustrated in FIGS. 8A and 8B. The 
modify credit group interface 180 enables the user to cus- 
tomize his/her class groups by providing functionality to 
perform such operations as adding and removing instru- 
ments from a class group, as illustrated in FIG. 8 A. For 
instance, for a selected credit group 182, a list 183 of 
instruments in that credit group is provided. Unassigned 
instruments can be added and member instruments can be 
removed. Further, credit groups 182 can be added and 
deleted via buttons 182, 185, respectively. In FIG. 8B, each 
credit group 182 may have bands of maturity 186 defined 
(i.e., added or deleted). Each class group preferably includes 
instruments that are closely related because the instruments 
in each class group are given the same credit preference 
setting, and therefore, the credit preference setting process 
may be simplified. 

Referring back to the credit preference interface 170 of 
FIG. 7, a preference setting column 187 provides the credit 
preference setting designated for the corresponding legal 
entity 183. The credit preference settings for any legal entity 
can be modified or selected via a drop-down dialog box 188. 
From the drop-down dialog box 188, the user can select 
from a list of predefined credit preference option. For a new 
line binary, the user is prompted with a new line binary 
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interface 189 in which the user can enter a maturity. For 
complex, the user is prompted with a complex preference 
interface 190 (FIG. 9B) in which the user can enter the 
exposure for each maturity band. 

With reference back to FIG. 7, the complex credit pref- 5 
ere nee settings and the RQ may be provided for each 
instruments designated as such by selecting an appropriate 
legal entity and then selecting the Complex Bands button 
194. 

If the user does not set a particular preference for a io 
particular counterparty, then the credit preference will be 
assumed to be a simple binary (no). If after Initially setting 
these preferences a new counterparty is added to the system, 
the preference for the new counterparty will be binary (no) 
for all users until they have specifically set a credit prefer- 15 
ence for the new counterparty. 

The level column 196 displays the business unit's desig- 
nation for each legal entity as to the levels A, B or C. The 
level set for each legal entity may be provided by the system 
10 via various interfaces such as a market detail interface 20 
(described below with reference to FIG. 15) to provide the 
trader with information with regard to the creditworthiness 
of the counterparty. Thus, a business unit may assign one of 
the levels A, B or C against each legal, entity. This is 
essentially a quick reference of credit worthiness for the 25 
user. 

The columns 198 labeled S&P and Moody are industry 
credit ratings that are integrated into the credit preference 
interface 170. The industry credit ratings may be down- 
loaded on a subscription basis via external communication 30 
interface link interface 62 (FIG. 2). Lastly, the last modified 
column and the modified by column identify the time and 
person that last modified that credit setting. As mentioned 
before, access to modify any of the credit preferences should 
be limited to a finance officer or credit officer of the legal 35 
entity. 

It should be noted that the credit preference settings may 
be transferred via electron file transfer or inputted manually 
on-line at anytime, and as often as the user desires. Further, 
. updates may be made for all credit groups and legal entities, 40 
or alternatively, updates can be just for individual settings. 

In addition, the credit preferences interface 172 includes 
a BU Info button 202 which, if selected, brings up a business 
unit data interface 204, as illustrated in FIG. 10. The 
business unit data interface 204 enables the users to view 45 
helpful internal information about other legal entities. The 
respective business units define what information is included 
in the business unit data interface. For example, the business 
unit data interface 204 of FIG. 10 provides the internal 
facility number, telephone number, internal reference 50 
number, internal net MTM, internal gross MTM, and inter- 
nal number deals of a business unit. Alternatively, a business 
unit may include a contact name or other business unit 
specific data. 

Accordingly, the credit preference logic of the present 55 
invention can be illustrated graphically as shown in FIG. 11 
For purposes of FIG. 11, it is assumed that business unit (i) 
belongs to legal entity (i) where i=l, 2, and 3, and business 
unit (j) belongs to LE (j) where 2, and 3. Accordingly, 
FIG. 11 illustrates a portion of the credit data which is stored 60 
by the system 10 in order to implement the credit preference 
feature of the present invention. Each column represents the 
credit preference (i.e., binary, line binary, or complex) which 
is stored anonymously for each business unit against each 
legal entity across all credit groups. The vertical and hori- 65 
zontal bars 210 represent the information which business 
unit (3) requires to determine the credit preference status of 
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an order. The information in columns 210 provides the credit 
preferences which business unit (3) has set against all other 
legal entity, and row 211 provides the credit preferences 
which all other business unit s have set against business unit 
(3)'s legal entity, that is, legal entity (3). The depth 216 of 
the graph is divided into the different credit groups such as 
switch, derivative, and foreign exchange. 

The triangles 212, 214 mark the cells that include the 
information which is used by business unit (3) to encode a 
specific order from business unit (5) of legal entity (5) with 
credit status information for presentation to the user via one 
or more of the interfaces described herein. In a preferred 
embodiment, the credit preference feature of the present 
invention color codes the credit preference status of each 
order from the perspective of the viewing business unit. 
Alternatively, another method of encoding the credit pref- 
erence status of an order may include adding a character 
notation such as an asterisk or star to an order, as may be 
desired if the user is color blind. 

Each order is color coded according to the credit prefer- 
ences marked by the triangle 212, which corresponds to 
what the order placer's business unit has set against business 
unit (3)'s legal entity, and the triangle 214, which corre- 
sponds to what business unit (3) has set against the order 
placer's legal entity. The order is evaluated according to the 
credit preference defmed in the cells marked by the triangles 
212, 214, and the results can be displayed to the user via the 
color coding scheme set forth below where true means that 
the order passes the credit preference of the setting party and 
false means that the order does not pass the credit preference 
of the setting party: 



Triangle 212 


Triangle 214 


Color 


False 


False 


RED 


False 


True 


YELLOW 


True 


False 


RED 


True 


True 


GREEN 



Thus, each order is color coded to communicate to the 
user the tradability of the bids and offers in the market based 
on the preferences of both users. The color coding method- 
ology described herein is used in both the market entry 
interface (described below with reference to FIG. 12) and 
the market detail interface (described below with reference 
to FIG. 15). For the present embodiment of the invention, 
the following meanings are associated with the cited colors: 
GREEN: The price passes the credit preferences of both 
parties, and the counterparties are free to trade. Any 
trade that is shown in green can be freely traded by the 
trader, and credit approval is assumed to be in place. 
YELLOW: The price posted is free to trade by the viewer, 
but the poster of the price has excluded the viewer from 
his/her credit preferences. If the price is colored yellow, 
a deal may be allowed provided that the party who 
placed the passive order allows mutual puts, and the 
credit over-ride process which is described below is 
completed. The viewer can attempt to trade by sending 
a message (thereby initiating the credit over-ride 
process) to the poster of the price which discloses the 
name and/or identity of the viewer, along with a mutual 
put maturity entered by the viewer. The poster then has 
the opportunity to accept, accept subject to credit (in 
either case, the poster may also reduce the maturity of 
the mutual put), or decline. The poster's name will not 
be released to the viewer until a trade is executed. The 
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posted price will remain available to all other traders on 
the system 10 until a trade is completed. If the order 
trades to another viewer, then the credit over-ride 
process will be terminated. 
RED: The price posted is excluded by the viewer's own 
preferences even though the poster is (may be) clear to 
trade. In this situation, the viewer is not free to trade 
since it is the viewer's own credit preference that the 
viewer set which is preventing the trade. 
BLUE: The price is the viewer's own order. 
WHITE: Only used in the market entry interface 250 
(FIG. 12) to display prices where there are multiple 
orders at the best price with differing codes. Thus, the 
viewer is notified to view the market details interface 
for more information. 
In the over- ride process mentioned above, if the viewer 
sees a price coded yellow that he/she wishes to trade, then 
the viewer may activate the over-ride process. The over-ride 
process begins by prompting the posting party with a request 
for an order quantity. The message sent to the poster 
essentially states that the viewer, which is identified by name 
in the message, wishes to trade a stated quantity and that the 
receiving party has a stated period of time to respond, for 
instance, 15 seconds. The viewer will then see a copy of 
his/her message and a clock which displays the countdown 
of the stated time to the poster The poster receives the 
message and can decline or accept. If the poster declines, 
then the viewer is informed accordingly. If the poster 
accepts, then the poster has the option to add a mutual put 
maturity and request a small price adjustment, which will be 
stated in a specified number of months. The viewer cannot 
back out of the trade while the clock is running (unless a 
price adjustment is requested). Further, at no time is the 
poster in a trade until all steps arc complete. 

Hie process by which passive orders are color coded is 
described at this point. Regardless of the credit preference 
type, the trader workstation 20 generates a maximum matu- 
rity value that determines how an order will be color coded. 
The maximum maturity value is in the form of an integer n 
digits in length, with the right-most two digits representing 
days, and the left (n-2) digits representing months. There- 
fore 12000 represents 10 years, 3600 represents 36 months, 
and 114 represents 1 month, 14 days. The method by which 
credit preferences are converted to a maximum maturity 
value is represented by Table 2 below. 

TABLE 2 



Preference 
Type 



Maximum Maturity 



Binary No 
Binary Yes 
Line Binary 



Complex 



-2 31 , the smallest possible integer value 
2 32 -l, the largest possible integer value 
The maximum maturity associated with 
the preference (e.g., Line Binary/12 has 
a max maturity of 1200) 
The maturity of the highest band with an 
exposure amount greater than zero, 
(e. g., The following complex preference 
would have a max maturity of 6000) 



Mat Band 


Exposure 


100 


10,000,000 


600 


5,000,000 


1200 


3,000,000 


3600 


1,000,000 


6000 


500,000 


12000 


0 



25 



55 



65 



32 
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be traded, the maximum maturity for the order's instrument 
is compared to the maximum maturity of the credit prefer- 
ence. If the instrument's maxium maturity is greater than 
that of the credit preference, then the order may be traded, 
otherwise it cannot be traded. 

Note that the maximum maturity assigned to a Binary-No 
preference will be lower than that of any instrument, effec- 
tively making all instruments untradeable. Likewise, the 
maximum maturity of a Binary-Yes preference will exceed 
that of any instrument. 

In order to determine the appropriate color code, the trade 
workstation 20 maintains two lists for each instrument class. 
One list includes the credit preferences that the viewer has 
set against all other legal entities for that instrument class. 
This list may be referred to as MY_PREFS. The other list 
includes the credit preferences that all other business units 
have set against the viewing legal entity for that instrument 
class. This list may be referred to as OTHER_PREFS. Each 
of these lists contains the following data: 

Business Unit ID (Only used for OTIIER_PREFS) 

Legal Entity ID (Only used for MY_PREFS) 

Maximnum Maturity 

Credit Level (Only used for MY_PREFS) 
Consider, for instance, an order for an arbitrary FRA 
instrument placed by business unit (1) of legal entity (1). 
When the order is broadcast out to a plurality of traders 20 
(i.e., viewers), the order will include the following informa- 
tion: 

Business unit of trader placing order: business unit (1) 
Legal entity of trader placing order: legal entity (1) 
Maximum Maturity of order: 3600 (for example) 
In order to color code the order, the viewing party must 
extract and utilize his/her credit preference against legal 
entity (1) from the FRA MY_PREFS list, and business unit 
(l)'s preference against him/her from the FRA OTHER_ 
PREFS list. From the credit preferences extracted, the color 
of the order as it will appear to the trader is as defined in 
Table 3 below. 

TABLE 3 



MY^PREFS 






PREFERENCE 


OTHER_PREFS 




max maturity>= 


PREFERENCE 




3600 


max maturity>«-3600 


Color of Order 


false 


false 


red 


false 


true 


red 


true 


false 


yellow 


true 


true 


green 



50 



Every instrument in the system 10 possesses a maximum 
maturity value. To determine whether a particular order can 



Also, note that the MY_PREFS list may contain a credit 
level (e.g., which may be associated with the order and 
presented to the viewer. 

Accordingly, when the user logs into the system 10, the 
user populates the MY_PREFS and OTHER_PREFS lists 
for the instrument classes for use by the credit preference 
module 76 (FIG. 3). This is achieved by the central pro- 
cessing center 12 sending to A trader workstations 20 that is 
logging-on one or more messages including the 
MY__PREFS and OTHER_PREFS lists from the database 
66 on the hard disk 64 (FIG. 2). 

When a user changes a credit preference assigned to a 
legal entity for a particular credit group in a way which 
causes the maximum maturity of the credit preference to 
change, the user will receive updates to MY_PREFS from 
the central processing center 12. Also, any user within the 
affected legal entity who is logged on to system 10 will 
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receive an update to OTHER„PREFS. Changes to complex 
preferences do not require such an update unless the zero 
band is changed (thus modifying the maximum maturity). If 
the user changes the credit level associated with a legal 
entity, the user will receive an update to MY_PREFS. 5 

However, these two updates should not be performed at 
the time the changes arc made, as doing so could allow a 
user to determine the legal entity that placed an order by 
methodically changing his/her credit preferences against 
each legal entity from a green state to a red state until the 10 
order changed color. Instead, the required updates will be 
collected and sent out on an periodic basis. Also, to discour- 
age discovery of a counterparty's identity by assigning a 
unique credit level to a single legal entity, each credit level 
should be assigned to either no legal entity, or to more than 15 
one legal entity. 

From the command center interface 130, a user may enter 
the market entry interface 250, as illustrated in FIG. 12. At 
the market entry interface 250, the user can simultaneously 
monitor numerous markets and place orders, including bids 20 
and offers. The market entry interface 250 also allows the 
trader to select any instrument(s) to be displayed, and 
multiple market entry interfaces 250 with various trading 
functions (e.g., common FRA on one interface, SWAP on 
another interface, and Switches on yet another interface) 25 
may be opened on the trader's desktop simultaneously. The 
market entry interface 250 is designed to present the sum of 
the best bid and ask, and the act of trading by any two parties 
by a flashing volume indicator in the top right-hand corner. 
Thus, the market entry interface 250 enables a trader to 30 
easily monitor many different markets with relative ease and 
utility. It should be noted that the system 10 does not 
perform auto-matching of orders, but allows the user to 
maintain control of the trading process at all times. The 
system 10 does this by introducing the concepts of active 35 
and passive orders. A passive order is an order placed in the 
system 10 for a particular instrument, for a particular 
quantity, at a specific price, for a particular time period (see 
order types below). An active order is when a user decides 
to trade a passive order displayed in the system 10, and is 40 
usually only required to provide the quantity. Thus, there can 
be active or passive bids and offers. 

The user may customize the market entry interface 250 by 
adding and removing instruments (i.e., markets) displayed in 
the instrument display window 252. The user may add new 45 
markets by entering an instrument symbol (according to the 
symbology of the present invention) into instrument identi- 
fier field 254. The user may also want to define groups of 
instruments which can be saved as profiles and viewed 
together. Profiles allows the user to organize multiple mar- 50 
kets by like attributes. The profile being viewed is displayed 
in the profile display field 256. The profile display field 256 
is a pull down menu that lists the other profiles defined by 
the user. Until the user defines a first profile, the profile 
display field 256 is set to default. 55 

Individual markets displayed in the instrument display 
window 252 are divided into four columns: instrument, best 
bid, best ask, and info. The instrument column displays the 
instrument name (i.e., the symbol, alias or a security 
identifier). The best bid column displays the best bid 60 
information, defined herein as the orders that are at the best 
price. The best bid information includes a relatively large 
central number that displays the least two significant digits 
of the price, a bottom left number that displays all but the 
least two significant digits of the price, a bottom right 65 
number that displays any volume or quantity currently 
trading, and a top right number that displays the quantity of 
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currency units in millions. Depending on the precision 
desired, a greater or lesser number of digits can be displayed 
as the larger central number. The precision of the displayed 
central numbers is defmed for each instrument, and may, for 
example, include 2, 3, 4, or more digits. The best ask column 
is substantially identical in format to the best bid column, 
but displays the best asking price rather than the best bid 
price. The info column provides space for data items that the 
user may select to view, as defmed in an info window 258. 
In the present embodiment, three items arc defmed in the 
info window 258, and thus, the corresponding information 
for the instrument will be listed in the info column. 

The system 10 provides users with a symbol construction 
interface 270, as illustrated in FIG. 13, that can be accessed 
via a Lookup button 272 from the market entry screen 250. 
The symbol construction interface 270 functions to aid the 
user in selecting instrument for display in the instrument 
display window 252. From the symbol construction inter- 
face 270, the user can view available aliases in window 273, 
explode a symbol (i.e., view a list of underlying parameters 
associated with the symbol, for example, payment date) via 
the Explode Symbol button 274, select symbols to be added 
to a profile via the Add to Profile button 276, and construct 
new symbols or aliases via the Build Symbol button 278. 
The symbol construction interface 270 also provides error 
checking such that only valid symbols can be selected. An 
instrument should exist in the database to be valid, and not 
all combinations will exist. For additional verification, the 
symbol explode function of the Explode Symbol button 274 
enables essentially all aspects of the instrument to be dis- 
played in detail. Thus, the explode symbol feature provides 
a complete detailed description of the instrument in Symbol 
window 280. 

The symbol construction interface 270 screen also enables 
the user to search for groups of symbols by at least partially 
filling out the input parameters 282 located above a Search 
Options button 284, and then selecting the Search Options 
button 284. The input parameters 282 include various non- 
commercial terms of an instrument that can be negotiated 
following a transaction. For instance, as shown in FIG. 13, 
the input parameters 282 include class of instrument, 
currency, start month, end month, over, FLOPT, and special 
rules. By at least partially filling in these parameters, the user 
can search for similar instruments which are displayed in 
window 280. 

Referring back to market entry interface of FIG. 12, it is 
noted that the prices displayed in the best bid and best ask 
columns are encoded with credit information using the color 
scheme described above. As previously mentioned, color- 
blind users can have the color coding scheme replaced by a 
symbol scheme in which different symbols are positioned 
next to the respective prices to indicate the credit status of 
the order. The symbol scheme may be chosen by the user 
under the Environment tab of the preference interface 148 
(see FIG. 6B). 

It should also be noted that the inventors of the present 
invention are not presently aware of any electronic trading 
system that offers color-based credit preference pre- 
screening such as that disclosed herein. The present inven- 
tion provides color-based credit preference pre-screening 
because, unlike the prior art systems which only show the 
best dealable price or the best minimum quantity, the present 
invention shows all prices (bids and offers), irrespective of 
their credit preferences. Thus, the user can be provided with 
as wide of a view of the markets as the user desires. 
Advantageously, the color coding enables the user to visu- 
ally determine virtually instantaneously what bids and offers 
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arc tradable based on the credit preferences of the trader and 
the counterparty. 

Once the user has entered the desired fmancial instru- 
ments in the market entry interface 250 via the symbology, 
the best bid and offers for each of the desired instruments 
will be displayed in the instrument display window 252. The 
best bid and best offer prices display in window 252 are 
different from many prior art systems because they arc the 
absolute best bid and best offer at the stated quantity. 
Because of the unique color coding scheme, the user is able 
to quickly tell whether or not the bid or offer is tradable by 
him/her. If the user so desires, the user can select a fmancial 
instrument with the pointing device 86 (FIG. 3), such as a 
mouse, so as to highlight the row in the instrument display 
window 252 for that instrument. Once the financial instru- 
ment is highlighted, the user may perform one of several 
functions provided for by the function bar 290, each of 
which is described below: 

FXPL Function: Th is explodes the instrument symbol 
into a full description of the contract, and mirrors the 
confirmation 

HIT, LIFr, ORD Functions: These three buttons allow a 
user to select an instrument and then place a new order, 
or execute an active order, by hitting or lifting the 
desired respective bid or offer. The HIT, LIFr, ORD 
functions can also be carried out by double clicking the 
mouse in the screen itself. 

RFP Function: request-for-price messages are an impor- 
tant tool to allow the market to communicate. If a trader 
wishes to see a market, a broker will be contacted via 
the telephone, and the broker will in turn phone other 
traders to drum up interest Using the system 10 of the 
present invention, the same result can be achieved 
instantaneously by sending an RFP to all registered 
users This message may be displayed in the command 
center interface 130 of other users, informing them of 
a RFP in the named instrument. In addition, because 
derivatives traders are often trading more than one 
fmancial instrument, and sometimes in more than one 
currency, derivatives traders will often have multiple 
passive orders. The present invention provides at least 
three order management functions to facilitate the 
canceling or temporarily suspending the order. This 
may be an important functionality when the market is 
moving quickly, or if the position of a trader suddenly 
changes. 

XLST Function: This function cancels the last passive 
order placed by the trader. Therefore, if a user submits 
an order and immediately changes his or her mind, the 
order can be canceled without the need to select the 
order individually. 

XALL Function: This function allows the user to cancel 
all his or her outstanding passive orders in one key 
stroke. 

REF Function: This function allows the user to suspend or 
place all orders under reference. This is an alternative 
to canceling orders one by one. For instance, if a user 
is expecting news that may affect only a few outstand- 
ing orders, it may be safer to place all orders under 
reference, and individually re-release the orders the 
trader expects not to be affected back into the market. 

DEL Function: This function allows the user to delete a 
market from the profile. 

In specific regard to the ORD) button in the function bar 
290, a user can submit a passive order by selecting the ORD 
button If the ORD button is selected, a passive order 
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interface 294 is provided to the user, as illustrated in FIG. 
14A. From the passive order interface 294, the user can 
place a passive order such as a bid (i.e., buy) or an ask (i.e., 
sell). The user enters a price, quantity, and selects how long 
5 the order will be good. The price will default to current 
market level so the user may only need to enter the last two 
digits of the price. For quantity, the system 10 recognizes m, 
mm and b for thousands, millions and billions, respectively. 
The system 10 allows the following order types to be entered 
10 under the good until option: 

good until logout (default) — Requires the user to be 

logged on and to monitor the orders status, 
good until time — The user will be prompted to enter a 
time (in his or her own time zone). This order does not 
15 require the user to be logged on and will be canceled 
automatically by the system 10 at the appropriate time, 
good until canceled — This order again does not require 
the user to be logged on, but must be canceled by the 
user, 

20 The system checks any new orders for reasonableness (or 
"framing") as they are placed. For example, a bid cannot be 
higher than the existing offer without the user double check- 
ing. The tab key, enter key, or the mouse can be used to 
navigate through the passive order interface 294. Upon 

25 selecting the OK button, the order is submitted into the 
system 10 and the user is returned to the market entry 
interface 250. 

In specific regard to the HIT and LIFT buttons in the 
function bar 290, a user can initiate active orders by hitting 

30 a bid (i.e., sell) or lifting an ask (i.e., buy). By selecting 
either the HIT or LIFT button, a hit order window or a lift 
order window is presented to the user. For example, a hit 
order window 296 is illustrated in FIG. 14B. The hit order 
window 296 is substantially identical to the lift order win- 

35 dow. As shown, the hit order window 296 identifies the 
instrument and order price. Further, the user is presented 
with a transaction quantity which is initially set for the full 
amount being offered by the counterparty. The user is 
allowed to reduce the quantity figure. The user is not allowed 

40 at this point to increase the quantity figure because the 
counterparty has already indicated the quantity they are 
desiring to sell. Upon selecting the OK button, the order is 
executed by the system in the manner described below, and 
the user is returned to the market entry interface 250. 

45 In addition to the above functions provided by the func- 
tion bar 290, if the user wants to see the full depth and breath 
of a particular market in a particular financial instrument, the 
user can select (e.g., highlight) an instrument in the instru- 
ment display window 252 and then click on the MDS button 

50 292. This will launch the market detail interface 302, as 
illustrated in FIG. 15 for the highlighted instrument. 

The market detail interface 302 enables a trader to view 
essentially all the orders in the market for a particular 
instrument, both bids and offers. The bid orders are listed in 

55 a bid window 304 where the credit levels (e.g., A, B or C), 
bid quantities and bid prices are provided. The offer orders 
(i.e., ask orders) are listed in ask window 306 where the ask 
prices, ask quantities and credit levels are provided. As with 
the market entry interface 250, the orders are color-coded 

60 with the appropriate credit preferences. This is a significant 
departure from many prior art systems which only show the 
best dealable price or blended prices. 

In the market detail interface 302, orders are individually 
listed in the bid window 304 or the ask window 306 in order 

65 of price, and then according to the time the orders were 
entered into the market. The user has the ability to select any 
order on the screen and hit or lift the order, assuming of 
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course that the respective credit preferences will permit a 
trade. The user is provided with a function bar 308, which 
is substantially the same as function bar 290. Particularly, 
the buttons of the function bar 308 are substantially identi- 
cally to those on the function bar 290 except that they only 5 
apply to a particular instrument while the buttons of the 
function bar 290 apply against multiple instruments. Further, 
a fair price indicator, spot/setting indicator (i.e., the LIBOR 
for that day), and last traded price indicator are provided 
along the bottom of the bid window 304 and ask window iu 
306. The last trade pricing may be replaced by volume, 
duration, RQ, last close price, etc. 

An advantage of the market detail interface 302 is that the 
user is not restricted to trading only the best price or first 
order. At no point in the process will any orders be auto- 15 
matically matched against each other by the system 10. The 
user is in complete control of the order flow process. 

Thus, the user can execute both passive and active orders 
from either the market detail interface 302 or the market 
entry interface 250. At either interface 250, 302, if the user 20 
wants to execute a trade, then the user only need to highlight 
the desired bid or offer and select the corresponding function 
button from the respective function bar 290, 308 to initiate 
the transaction. Although the semantics of placing, 
changing, and canceling orders can be relatively complex, 25 
the user is shielded from this wherever possible by the 
system 10. 

Each order entered into the system 10 is placed into a 
queue based on price and time received. A change to the 
order may or may not affect the order's place in the queue. 30 
Any change of price will move the order up or down in the 
queue depending on the price level. Any decrease in the 
volume of the order will not affect the order's place in the 
queue. Any increase in volume will result in the previous 
amount holding its place and a new order placed for the 35 
balance. 

Effective electronic trading should be intuitive, fast and 
reliable. In order to facilitate this, the present invention is 
designed to maximize a user's efficiency. The system 10 
enables the user to place passive orders from either the 40 
market entry interface 250 or market details interface 302 
using the input device 86. For instance, the user may double 
click on the instrument name or may select the ORD button 
of the function bar 290, 308 in order to launch the passive 
order interface 294. 45 

Once an order has been submitted, it will immediately be 
updated to the market entry interfaces 250 and market 
details interfaces 302 of other users, providing the user has 
a current subscription (i.e., field setting) to the instrument. 

For monitoring the status of a user's outstanding (or open) 50 
passive orders, and for making quick adjustments to those 
orders, the present invention has a facility known as an 
outstanding order blotter 320, as illustrated in FIG. 16. The 
outstanding order blotter 320 summarizes all outstanding 
passive orders and provides the user with the ability to 55 
confirm the terms of the trade, the symbol, and the type of 
order. In addition, the outstanding order blotter 320 enables 
the user to quickly change the price, quantity, or good until 
status via drop-down menus that appear when an order is 
selected. From the outstanding order blotter 320, the user 60 
may also place new orders and/or cancel a particular order 
in the market. Thus, the outstanding order blotter 320 gives 
the user the ability to manage his/her current passive orders 
in the market from a single interface. As with the market 
entry interface 250 and market detail interface 302, the user 65 
is provided with cancel all, cancel last, and refer-all func- 
tions via the outstanding order blotter 320. This is a signifi- 
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cant advancement over many prior art systems in that not 
only does the system 10 offer a facility to track all current 
passive orders, but the system 10 also enables the user to 
modify, add or delete passive orders from the outstanding 
order blotter 320 without returning to the market entry 
interface 250 or market detail interface 302. 

For executed or canceled orders, the user is provided a 
client monitor 330, as illustrated in FIG. 17. From the client 
monitor 330, the user has access to completed or canceled 
trades. Thus, the client monitor 330 enables the user to 
quickly see what orders have been executed or canceled, and 
to look back over time to sec pervious days trades. 
Preferably, historical transactions will be available for one 
month via the client monitor 330. 

The outstanding order blotter 320 and client monitor 330 
enable a user to manage his/her diverse trading activities. 
From either blotter, the user can monitor the status of orders 
and executed or canceled trades. Both of the outstanding 
order blotter 320 and client monitor 330 can be accessed 
from the command center interface 130. Further, the blotter 
320 and monitor 330 are updated automatically if the user 
submits an order via one of the other interfaces. 

The system 10 permits active orders (i.e., those where a 
trader hits or lifts a passive order) to be placed from either 
the market entry interface 250 or market detail interface 302 
via the MIT and LIFT buttons on the function bars 290, 308. 
The system 10 differs from many prior art systems in that 
two passive orders will not be executed against each other 
automatically. An active order from an active user is 
required for execution. Furthermore, there will be one active 
and one passive user for each trade. This means choice 
(where bid equals order) or even backwardation (where bid 
is higher than order) markets are possible. Accordingly, for 
a transaction to be completed in the system 10, an action 
must be performed against a passive order. 

Once an active order has been placed in the system 10, the 
execution process is completed. An execution notification 
message 340, as illustrated in FIG. 18, is sent to both 
counterparties, describing the transaction and disclosing the 
names of the counterparties. Note, this is the first point in the 
transaction that the counterparties are identified to one 
another. The system 10 ensures that both users receive the 
message before the trade is finally completed. This does not 
require any form of action from either user, the market 
interface module 74 (FIG. 3) of each trader responds for the 
respective user. This validation ensures that, in the unlikely 
event that a connection is lost during this process, a user 
does not have a position of which he or she is unaware. 

The system 10 is designed to ensure that a user cannot 
execute a passive order which has been canceled or is no 
longer available. This is done by checking to verify that the 
connection between all trading counterparties is live at all 
times. In the event that the connection is lost or broken, all 
orders from a user which loses connection to the system 10 
are automatically suspended. Following the execution, the 
client monitor 330 is updated with the transaction. 

The execution notification message 340 (FIG. 18) pro- 
vides the users the opportunity to increase the quantity of a 
trade once an initial trade has been executed. One of the 
users can insert a quantity in the will-do- mo re field 342 
which represents an additional quantity to the original 
amount This feature is designed to enable a user who has a 
large quantity to trade to place a passive order for just a 
smaller portion initially. Users often want the ability to 
increase the quantity of an order when they have a large 
quantity to transact. This is because large orders in the 
market often tend to adversely move the price of the market 
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as market participants back off such large size. The ability identifies the transaction. However, it is recognized that 

for the passive trader to conduct an anonymous dialogue via various other parameters and transactional data can be 

the system 10 for increasing the size of a transaction after an included as appropriate for the nature, type and subject 

initial transaction for a smaller size has been executed is an matter of the transaction. 

additional difference between the system 10 and many prior 5 In addition to the interactive trading functionality 

art systems. In operation, once an amount has been entered described herein, the system 10 also offers traders a trading 

into the will-do-more field 342 and the Submit button 344 methodology for dealing with risk management problems 

selected, the counterparty is provided with the request for unique to interest rate swap dealers. In particular, over the 

more. The counterparty is given a discrete period of time to last few years, a new market has emerged as a result of 

respond to the request to do more, after which the request 10 interest rate swap dealers* need to better manage their risks 

lapses. If the counterparty wants to trade more, then the associated with changes in interest rates on their growing 

counterparty can accept the amount requested, reject the interest rate swap portfolios. With these markets becoming 

amount by selecting the Reject button 346, or the counter- more competitive, bid-offer spreads are narrowing consid- 

party can request a different amount that is then present back crably. This factor, combined with the wide spreads of 

to the user who then has a discrete period of time to respond. 15 exchange traded Eurodollar futures, has contributed to the 

The counterparties can exchange offers to increase the use of exchange traded contracts for hedging short-term 

quantity as many times as they desire until an addition risks being expensive and sub-optimal. As a result, the 

amount is agreed upon or a decision is made not to do more. switch was created. A switch is simply the simultaneous 

This function should preferably be made available only if purchase and sale of a pair of similar forward rate agree- 

the active order clears the full market size at the current best 20 ments. This instrument, and the mutually offsetting need of 

price. In that case, either party may ask to do more. The a pair of derivative portfolio risk managers, provide an 

will-do-more feature enables the counterparties to increase improved risk management tool for a large portfolio of 

the size (amount of the trade), but not the price. The price is interest rate swaps. Despite the obvious advantages and 

preferably not affected. This process can go back and forth demand from risk managers, as a result of the complexity 

for some time and can continue as long as the will-do- 25 and time-consuming nature of completing a transaction, the 

quantity is fully accepted (i.e. can occur more than once). switch market has grown relatively slow. This may be 

Once completed by both parties, the system will combine all because risk managers are very wary of disclosing the exact 

will-do-more quantities and generate only one transaction nature and size of their own portfolios. Therefore, finding 

ticket for the total increased amount at the initial price. the counterparty that has the opposite need is often difficult. 

Following the execution of a trade, the system 10 enables 30 Typically, a dealer prepares a fax listing the days that the 
the parties to negotiate the non-commercial terms of the dealer needs to buy or sell, but not the amount or importance 
transaction. This process is referred to as term negotiation, of any given date. The dealer sends the listing to other risk 
and is effectuated through the negotiation window 350, as managers at other firms, or to voice brokers. From this bit of 
illustrated in FIG. 19. The term negotiation process is a incomplete information, transactions are eventually negoti- 
process where by both parties to a trade have the ability to 35 ated. While finding switches may be important, it is usually 
negotiate non -commercial terms of a transaction. In addition not urgent as compared to other more immediate tasks, such 
to the commercial terms, such as price, quantity, etc., as new executions or the hedging of large outright market 
derivative transactions also have non-commercial terms risks. As a result, the time is never quite right to focus on a 
which do not affect the price of the trade. While there are position that may be heavily weighted on one side and 
defaults, the parties may want to negotiate these terms. Once 40 matches another's position, but not perfectly. Voice brokers 
a trade has been executed, the system 10 will present the have tried to solve this by matching multiple faxes, but this 
parties with the option to negotiate via interface 350. The does not appear to be the solution, 
system does not force a party to complete this process The present invention goes several steps beyond these 
immediately, however, as the party may have other more efforts, and offers matching with the credit preferences of the 
important tasks to complete elsewhere. The negotiation 45 traders taken into account. The system 10 also demonstrates 
should, however, be completed within a reasonable time. fairness in any matching process. When the portfolios are so 
The active party (i.e., the trader that hit or lifted the order) large that each risk manager has a position on each day out 
will be presented with the terms 352 to be negotiated, over the life of his or her portfolio, the resulting combina- 
current values 354 which are editable (such as by a text tions can be huge. The rules, constraints and priorities are 
field), and default values 356 which are predefined in the 50 preferably structured in a way to demonstrate fairness of 
system. The trader may accept the system defaults by execution between users to the market participants, 
selecting button 358, or enter his/her own desired values and In a significant departure from known attempts by others, 
select the submit button 360. These values are sent to the the present invention offers traders a solution to the corn- 
passive trader (i.e., the trader that placed the order in the plexities of switch trading by creating an anonymous posi- 
system originally) who may also accept or enter his/her 55 tion discovery system called the switch engine. The objec- 
desired values. If an agreement cannot be reached, then the tive of the switch engine is to put a tool in the hands of risk 
defaults will be used. The status of these negotiations will be managers that allows them to perform anonymous switch 
displayed in the client monitor 330 of FIG. 17. transactions fast and efficiently without losing control of the 

Once a trade has been executed and the non-commercial process. The switch engine achieves this by having the 

terms have been negotiated, a trade confirmation is sent 60 trader manually input his/her position (i.e., interest rate risk 

automatically to the settlement contact of both business units portfolio) into the switch module 80 (FIG. 3) via a portfolio 

preferably via fax. The system 10 can also send the confir- interface 380 using variable rate index and currency for up 

mation via file transfers, e-mail, or any other suitable means to 180 days or more into the future, as illustrated by FIG. 20. 

of communication. Preferably, the trade confirmation Once a portfolio is inputted, the user must confirm its 

includes the quantity or volume traded, identification of the 65 accuracy by selecting the Apply button 381 before the 

financial instrument that was traded, price, date and time the positions can be used in the switch mechanism 35 of the 

execution is recorded, and a settlement ID that uniquely central processing center 12 (FIG. 2). 
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In addition, the system 10 can be configured to receive the 
position data via electronic transfer or some other suitable 
form of data transfer. This may include a transfer directly 
from the user's own risk management systems. Although 
some trader workstation 20 may need some customization to 5 
receive portfolios in this matter, the system 10 should 
support this capability. The nature of switch positions, 
particularly in the near term (defined as out to the maturity 
of each index), is relatively stable, and therefore, the on-line 
entry of portfolios by the user should be adequate for most 10 
traders. The inputted portfolio data is then sent from the 
trader 20 workstation to the switch mechanism 35 of the 
central processing center 12. 

With reference to the portfolio interface 380 of FIG. 20, 
an inputted column 382 represents the portfolio entered by 15 
the user, the traded column 384 is the cumulative amount 
traded by the user since the portfolio was entered in the 
inputted column 382. The net column 386 is the real-time 
position of the user given the portfolio inputted and the 
traded quantities in column 384. The user may restart at any 20 
time by rolling the net positions in net column 386 into the 
input column 382 by selecting the Roll button 388, or by 
clearing all the positions by selecting the Clear button 389. 

Once the position is inputted in the system 10, a switch 
interface 400, as illustrated in FIG, 21, is generated by the 25 
switch module 80 using his/her own position data from other 
traders entered on the respective trader workstations 20 and 
uploaded to the switch mechanism 35. The switch interface 
400 enables the user to search through the market, and view 
possible trading combinations of his/her portfolio and com- 30 
binations of his/her portfolio against positions from other 
counterparties which have been input into the system. This 
is referred to as position discovery. The switch interface 400 
can be reached by selecting the switch engine button in the 
tool bar 132 of the command center interface 130 (FIG. 5). 35 
For a given floating rate index (for example, a one month 
LIBOR) 402, the switch engine interface 400 lists the net 
positions 404 for each day 406 out 180 days. In addition, the 
possible switches 408, available switches 410, formulated 
forward rate 412, and a fair price 414 are also listed for each 40 
day 406. By selecting a day 406, the switch interface 400 
displays all possible switches against that day. Thus, the user 
can pick the days for which he/she is carrying the most risk. 
An advantageous feature of the switch interface is that the 
user is provided with only combinations where he/she has a 45 
position and someone else has the opposite position, and 
both parties satisfy each other's credit preferences as 
described above. 

The net position 404 is the position entered or modified by 
the user. Possible switches 408 are those switches for any 50 
given day with respect to the trader's own position. Note, a 
switch typically makes sense only if the trader's position is 
long one day and short on another day. 

The available switches 410 are positions in other coun- 
terparty portfolios that exactly offset the position of the user 55 
Note that the switch interface is configured to displays 
available switches up to the size of the user's own position, 
and preferably does not disclose the name(s) of any coun- 
terparties until after a trade has been completed. This 
ensures the anonymity of the user, and does not disclose any 60 
material position data to other traders. 

The forward rate 412 is the current market forward rate 
calculated by the system from other available market rates 
for the given date for the maturity of the underlying index 
maturity. The fair price 414 represents the relative price 65 
between the two underlying FRAs, which is the basis upon 
which forward rate agreements are traded. The fair price 414 



is calculated from live market data taken from other finan- 
cial instruments. While not designed to execute trades at the 
displayed fair price 414, the fair prices arc an aid to users in 
gauging the fair value of the market. 

Once a user has found a switch that matches the needs of 
the user, that is shown as an available switch 410, then the 
user may send a request for switch message by selecting the 
request for switch (RFS) button 416. In response thereto, an 
RFS message is sent anonymously to only the other coun- 
terparties of the selected offsetting positions. Anyone of the 
receiving counterparties may then add the symbol automati- 
cally into a market entry profile by selecting (i.e., clicking 
on) the message and completing the transaction utilizing the 
market entry interface 250, as described herein. Upon 
completion of a switch by the switch mechanism 35, the 
portfolio's of the counterparties are automatically updated to 
reflect the switch. In accordance with a feature of the switch 
engine, switch transactions can be accomplished in real- 
time. 

As an example of a switch, a trader viewing the switch 
interface 400 may select (i.e., highlight) the "Thurs., August 
21" position, and then select the RFS button 416. The 
passive order interface 294 (FIG. 14A) then prompts the 
trader with a quantity and price which the trader may 
modify. The trader may then submit the request' for the 
switch. All anonymous counterparties that have an offsetting 
position then receive a message in command center interface 
130 (FIG. 5) notifying the counterparty of the anonymous 
request for a switch. Any one of the counterparties may then 
select the request message which causes the request to be 
displayed in the market entry interface 250 (FIG. 12). From 
the market entry interface 250, the counterparty can hit the 
request for switch or submit their own passive order. 

The trader can update or modify his/her portfolio by 
selecting the Update button 418, which launches portfolio 
interface 380, as described above. The trader can then select 
an inputted amount 382 or a traded amount 384 to enter or 
edit the displayed values as desired. 

It should be noted that the present invention has applica- 
tion in financial markets other than derivatives. For instance, 
in the inter-dealer market, a switch or swap may be a 
desirable means by which a risk or inventory short fall is 
off- set. In particular, a security may be borrowed or an open 
derivative position hedged with another position. For 
instance, in the U.S. Treasury bond market, it is conven- 
tional for traders to buy and sell securities, and to hedge with 
the newest or benchmark issues. The U.S. Treasury may 
issue new two year securities each month. For the first 
month, the new issue is the benchmark (or on-the-run) issue, 
and the other issues with a fmal maturity between one and 
two years are referred to as old issues. If a trader is asked to 
buy an old issue, then the trader will sell the on-the-run as 
a hedge since the on-the-run has the liquidity. Over time, the 
trader will most likely need to sell the old issue and buy back 
his/her hedge. A switch with another dealer that has an 
opposite position provides cost and risk effective method of 
effectuating such a trade. 

However, the unwillingness of traders to disclose their 
position has made bond switches difficult. Thus, the switch 
engine of the present invention is a solution. The principals 
of the switch engine can be successfully applied to bond 
switches, as well as other financial instrument switches. The 
switch engine interface 400 may need to be slightly modified 
wherein the instrument designation 402 is changed to reflect 
the new market, for instance, to Two Year U.S. Treasuries or 
30 FHLMC TBA. Further, the setting column 406 may be 
changed to reflect the individual securities which may be 
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switched, and the remaining columns should not need to be 
changed. However, a new column representing the duration 
of each security displayed should be added so that the 
securities can be duration weighed to ensure fairness. 

In addition to the switch engine, the system 10 provides 5 
trading methodologies referred to as the auction and switch 
auction. Although auctions arc held in a variety of markets, 
some of which arc electronic, the auction and switch auction 
have no known counterpart in the derivatives markets. The 
auction and switch auction trading methodologies were 10 
developed in order to provide an auto matching process for 
switches. However, the system 10 can use these auction 
methodologies for auto matching for a wide variety of other 
financial products, not just switches. 

Unlike traditional auctions, where once a trade is com- 15 
pleted the counterparties arc free from future financial 
commitments, with derivatives trading, the counterparties 
may end up with multi-year financial commitments to one 
another once a trade is executed. In order to deal with this 
relatively unique problem, the auction and switch auction 20 
take the credit preferences of the users into account. The 
auction methodologies herein are referred to as a two way 
Dutch auction with credit. In conducting such an auction, 
users submit orders into the auction module 81 of the trader 
workstation 20 (FIG. 3) which communicates the informa- 25 
tion to the auction mechanism 34 of the central processing 
center 12 (FIG. 2). The orders are submitted via an auction 
interface 430, as illustrated in FIG. 22A, by price, quantity, 
and action. 

With reference to FIG. 22A, the auction interface 430 30 
includes a queued orders window 432 into which the user 
enters an order, and a submitted orders window 434 which 
shows the orders submitted to the auction mechanism 34 via 
the auction module 81. Orders can be added via the Add 
button 436. Orders are moved from the queued orders 35 
window 432 to the submitted orders window 434 by high- 
lighting the order and then selecting the Submit button 438. 
All entered orders in the queued orders window 342 can be 
submitted at once by highlighting all the orders and then 
selecting the Submit All button 442. Prior to submitting an 40 
order, the orders in the queued orders window 432 can be 
edited via the Edit button 440 or canceled via the Cancel 
button 444 

In accordance with the auction, the orders are filled at 
their entered price or better, and between counterparties that 45 
satisfy the credit preferences of one another. The auction 
mechanism 34 then conducts the auction, preferably utiliz- 
ing the following constraints and priorities to ensure fair- 
ness. 

The auction price is calculated by finding the price at 50 
which the most volume is traded. Thus condition is sufficient 
to generate a fair price, and all transactions should be 
completed at this price. It is noted that this price is generated 
without taking credit into account. The matching of orders is 
completed to ensure that credit preferences (including com- 55 
plex rules) are safe guarded and to ensure that the minimum 
number of tickets are generated. The better submitted prices 
will have priority, and all orders at the auction-price are 
filled in proportion to each other. Under these constraints, 
the auction mechanism 34 executes the auction, matching 60 
users and generating a settlement list. The settlement list 
comprises the trades resulting from the auction. 

The confirmation process is substantially the same as that 
for interactive trades. The system 10 notifies the users of 
their fills. Finally, results will be made available to the user 65 
via a message to the command center interface 130 of each 
user. 
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In addition to the general auction facility described 
herein, the present invention also offers a dedicated limited 
auto-matching process for switches referred to as the switch 
auction. The switch auction does not have to be a full 
auction, in that the price may be set by the system 10. The 
price will, however, be available before the commencement 
of the matching. This will allow all users to understand the 
levels that will be used before entering into the switch 
auction. This also allows the users to maintain control of 
their positions. 

As with the general auction, the positions of each trader 
are loaded into the system 10 utilizing a switch auction 
interface 460, as illustrated in FIG. 22B. The switch auction 
interface 460 has two parts, an auction list 462 and an 
auction status 464. In the auction list 462, various auctions 
and their respective statuses arc listed by FLOPT and 
currency. In the auction status 464, the auction selected in 
the auction list 462 is displayed and identified (including the 
open and close day/time). The positions 466 for respective 
dates 468 are entered by a user, and do not need to add to 
zero, but should include positions of both signs (i.e., long 
and short). The rate 470 is the price at which the auction is 
conducted. The rate 470 is displayed a predetermined 
amount of time before the auction is conducted so that the 
participants have the opportunity to step out of the switch 
auction if they so desire. The rate is preferably based on 
available market factors, and may be calculated by a 
calcserver (as described below). The results column 472 is 
the total trade amounts resulting from the auction. The 
amount displayed in the results column 472 for a given date 
may be the cumulative amount from multiple transactions 
with multiple parties. Additional control buttons 474 enable 
the user to submit an order, cancel an order, cancel all orders, 
or change an order. The switch auction will auto-match the 
position, taking credit preferences of the users into account 
so that (1) a maximum volume is executed and (2) a 
minimum number of tickets is generated. 

The switch auction utilizes the above two rules to ensure 
fairness. No user will be given priority over any other user 
except as required to satisfy the respective credit prefer- 
ences. Preferably, only two-way switches will be offered. 
Switches are a risk management tool, and switches gener- 
ated between three counterparties introduces substantially 
more credit risk than a straight two-way switch. 

At this point, the calcserver which calculates the auction 
rate and price information, and other relevant data for 
operation of the system 10 is described. The calcserver 
provides the switch mechanism 35 with the forward rate for 
any given index for each day, the system price quoted in the 
market entry interface 250, and OTC derivative prices 
derived from the yield curve. The calcserver comprises a 
preprocessor, a zero curve server, a FRA server and a Swap 
server. The preprocessor gathers real-time data from outside 
data vendors (such as Reuter or Telerate) and from internal 
system sources (such as data normally entered into system 
10), and prepares the data for processing by the other 
components of the calcserver. The zero curve server reads in 
the market rates (including price and yield for a variety of 
class instruments such as money market rates, swap rates, 
future prices, swap spread, bond yields and FRA's) as 
provided by the preprocessor, and generates therefrom the 
zeros and discount factors for each currency and level of 
credit. In particular, a zero coupon yield curve (i.e., zero 
curve) comprises a set of points representing the calculated 
interest rate or discount fact from observable market rates 
across the term structure (e.g., 0 to 30 years) such that any 
cash flow can be discounted to today in one step without the 
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consideration with decompounding. Thus, there is a different calculated where gaps exist to improve accuracy. The cal- 

zero curve for each index/currency pair. The FRA and Swap culation of a normal swap rate and a synthetic swap rate are 

servers are instrument specific servers that calculate the same. The following equation for Z(t,) is the zero rate at 

forwards, RQ (as defmcd above), durations and fair prices. the particular coupon date: 

By way of example, the zero curve calculation starts from 5 
the instruments with the shortest term structure in the money 

market rates (MMs). The analytics for finding points on the ZtO = 
zero curve from MMs are as follow. The processed price of 
the MMs, end date of the MMs and the basis of the MMs 

(number of days in a year that the MMs is based on) are 10 
needed. All of these are stored in a database 64 (FIG. 2). The 

processed price is the only input that typically changes. The where swapRate is tradePriceAdjust, t, represents a coupon 

calculation represented by the equation below will generate date, and Y^.^tJ is the period in years between the two 

a new zero rate with the date of the end date of the MMs. The coupon dates. Once the trades have been executed and the 

result will be a new zero point which will be added to the rest 15 term negotiation process completed, the system will initiate 

of the generated zero points. The following equation for Z(t) an automatic confirmation process which, in an embodiment 

is the zero rate at the end date of the MMs: of the present invention, will follow existing market prac- 
tices. Accordingly, the system 10 will automatically send a 

t 3« fax confirmation message to each counterparty detailing the 

z(t) = (i + * mmsBasis ) ~ 1 20 transact i° D - Th e faxes should be sent immediately after a 

transaction is completed. The confirmations should follow a 
unique format, allowing the automatic transfer of these 

where Rmms is the processed price of MMs, and t is the time confirmations electronically. 

in days between the end date of the MMs and the current confirmation has been specially developed to allow 

d ate - 25 for a standard format covering all classes of financial 

After the MMs, the next instruments used according to contracts. The standard confirmation follows the following 

term structure are either the futures or FRA's. Since the format; 

futures and FRA's have similar term structures, a choice will c . . Ci r t „ ncn „ t - 

, . , . . . „ , ' ... . Section 1: Summary oi the transaction, 

be made on which ones to use. Initially the futures will be „ ^ , 

used because they have high liquidity. However, it is Sectlon 2: Counterparty details and commission, 

believed that when FRA's traded on the system 10 reach a 30 Section 3: Transaction details, 

high level of liquidity, they should be used instead. Section 4: Term negotiation 

When calculating zero points from the futures, the pro- This provides the users with adequate information to iden- 

cessed price, the future basis (number of days in a year that tify and/or record the transaction. The conformation, 

the future is based on), the start date of the future, the end however, may be sent to the traders any number of ways 

date of the future and the zero point of the start date are such as via e-mail, voice-mail, United States Postal Service, 

needed. This data about the future will come from the or commercial carrier (e.g., FedEx, UPS, etc.). Further, it is 

preprocessor which is used to represent the future. The zero noted that the information provided can take many other 

point at the start date is found from previous zero points formats within the scope of the present invention, 

through 4Q While the various interfaces to system 10 have been 

described herein as individual windows, it is noted that 

r , e- A v s ^ multiple windows can be integrated to form a main screen 

ztc)^\[\^futRa I e*j~^~r)(\ + z(s))^\ e -l 480 witn multipIe f rame s, as illustrated in FIG. 23. For 

instance, a tools area 432 provides the trader with a set of 
customized tools including graphs, market quotes, bond 
interpolation. The following equation for z(e) is the zero rate 45 prices lo yie i d converters, pricing tools, and MarketSheet™ 
at the end date of the future. applets. A service area 484 provides various interfaces as 

where futBasis is the number of days in a year that the future described above on a temporary basis. A message center 486 
is based off, futRate is the processed price of the future, e is displays the most recent RFP, RFS, Chat and administrative 
the end date minus current date, and s is the start date minus messages, and is preferably configured as a drop-down 
the current date. window to display multiple current messages. A status bar 

The calculation of the FRA zero points is the same as for 488 displays user status information. A workspace area 490 
the futures except that the processed price for the FRA and pr0 vides for the entering of data into dialog boxes in a 
the FRAbasis are used instead of the processed price for the non-intrusive manner, plus the execution of the data func- 
futurc and the futurcbasis. The information about the FRA uon . A warehouse area 492 stores the most commonly used 
will come from the preprocessor. 1 tie following equation for 55 interfaces in a tabbed format, allowing the trader to retain 
z(c) /ro is the zero rate at the end date of the FRA: their preferred set-up between sessions. Accordingly, the 

. main screen 480 provides enhanced functionality by inte- 
grating multiple interfaces in a single window. 
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IV. Operation 



The rest of the zero curve will be derived from swap As described above, the system 10 comprises the central 

information. For the first swap, the zero curve and the processing center 12 that may includes multiple servers 

discount factor at each coupon date are used to calculate the connected via an Internet-protocol network to the individual 

zero rate and the end date in the swap using the equation 65 counterparties trader workstation 20 which may be desktop 

below for Z(t„). When calculating other swap zero points, computer workstations. Because of the open system arc hi - 

gaps may exist in the zero curve. Synthetic swap rates are lecture of the system 10, the present invention may run 
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within the context of the internet browser 72 on the user's 
existing desktop computer 20. The desktop computer 20 
preferably includes an operating system platform for which 
a Java-enabled Internet browser is available. 

In order to provide the counterparties with anonymous 5 
credit preference based trading capability for a wide range of 
financial contracts where each side enters into a long-term 
contract with the others, the present invention is designed to 
be flexible enough to reflect several different measures of 
credit risk, as generally described below with reference to 10 
FIG. 24. 

With reference to flowchart 502 of FIG. 24, each business 
unit (counterparty) provides the group server 32 (FIG. 2) 
with detailed credit preferences for each potential counter- 
party business unit's legal entity The group server 32 then 35 
distributes the credit preference information in an anony- 
mous format to the trade workstation 20 which uses the 
credit preferences of each active business unit (counterparty) 
in the system 10 to prescreen the user's market orders (bids 
and offers) against the other counterparties' market orders. 20 
Thus, the credit preference module 76 (FIG. 3) of each trader 
receives the credit preference information defined by a first 
user with respect to a second user, as indicated by block 504. 
The credit preference module 76 then receives the credit 
preference information from the second user with respect to 25 
the first user, as indicated in block 506. The credit preference 
module 76 then determines which orders, on which financial 
instruments, and with which counterparties, the user can 
deal. This information is coding on the posted prices utiliz- 
ing color or another notational method such as symbols, as 30 
indicated in block 508. 

In accordance with an aspect of the present invention, the 
prescreening is a complex check to determine whether two 
particular counterparties will accept each other for a par- 35 
ticular class of financial instrument, for a particular amount 
and for a particular maturity. ITiis is a risk equivalent 
measurement, and is more than a simple yes/no preautho- 
rization matrix. More specifically, because each financial 
instrument has different credit qualities, it is possible for a 4Q 
particular counterparty to be willing to accept another par- 
ticular counterparty for one type of financial instrument but 
not another. Furthermore, it is also possible that a particular 
counterparty may accept the other for a particular financial 
instrument, but only for a certain length of time (i.e., 45 
maturity). The system 10 may also allow the user to accept 
counterparties for different amounts at different maturities. 

It is further noted that the system 10 divides counterpar- 
ties into legal entities. These legal entities may be further 
divided into individual business units. So, for example, 50 
Bank A may be a legal entity (counterparty) and Bank A 
might have a different business unit in three different cities 
(e.g., Tokyo, London, and New York). In this example, the 
counterparty credit information is available at the legal 
entity level. So, for instance, if Bank A wishes to allow each 55 
of its business units to set their own credit preferences for 
other counterparties, then these credit preferences will be 
listed against the legal entity level of all the other business 
units. In other words, business unit A at Bank A can not say 
it will trade with desk A of Bank B but not desk B of Bank 60 
B. Hie system 10 allows business units within a particular 
legal entity to inherit the credit preferences from other 
business units in the same legal entity family, if so desired. 

Once each business unit has inputted their individual 
credit preferences, this credit preference information is 65 
maintained locally at the inputting trader workstation 20, 
and transmitted to the group server 32 of the central pro- 
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cessing center 12, The central processing center then trans- 
mits a vector of encoded credit preference data to each user 
logged on, wherein the data represents that preferences of 
the user to the other legal entities and the preferences of 
other business units to that user's legal entity for the affected 
instrument classes. The encoded vector of credit preference 
data is accessible to any of the trader workstations 20 in the 
system 10; however, the sensitive credit information of other 
counterparties is not available. 

Once the user has inputted his/her business unit's credit 
preferences, the user is then able to select or filter messages 
on which financial instruments and in which currencies the 
user wishes to receive updates, messages and prompts. The 
filters can be selected via the user preference interface 148 
to customize the order information presented by the com- 
mand center interface 130. This screening capability is 
provided to the user in order to prevent him from being 
overwhelmed by, and to sort through, the possibly thousands 
of different financial instruments in up to or more than 14 
different currencies that the system 10 has the ability to 
handle. Once these filters have been inputted into the system 
10, the user is able to view trading information on the 
currencies and financial instruments that have been selected 
for the user. This means, for example, that if the user has 
selected US dollars only, then the user will preferably not 
see information on the Japanese Yen financial instruments 
which are in the system 10 for trading. 

Once the trading preferences of the user have been 
entered into the system 10, the user can proceed with 
trading. The user then activates the fully customizable, 
re-sizable market entry interface 250. The market entry 
interface 250 enables the user to input many different 
financial instruments which the user is interested in trading 
on one screen, and have any number of profiles wherein each 
profile is a collection of markets or a collection of financial 
contracts in the system 10. 

A preferred embodiment accomplishes the inputting and 
referencing of the various financial instruments through the 
use of a unique set of symbols referred to as symbology. The 
symbology of the present invention is based on a concept of 
subject based addressing whereby the user creates a symbol 
to uniquely defme any one of many complex financial 
instruments. The symbol denotes the financial instrument's 
parameters and attributes. The standardized symbology of 
the present invention is designed such that the users of the 
system 10 will recognize the meaning of the symbol when 
the users view the symbols. To further help the users 
understand which financial instrument they are trading, a 
symbol may be identified by the full subject name, an alias 
(in the case of the most commonly traded instruments), or a 
unique identifier (e.g., such as a numeric code). In order to 
help the users use the symbology to properly express the 
financial instruments they want to trade, the system 10 
allows the users to construct symbols utilizing the symbol 
construction interface 270 (FIG. 13). 

The symbology of the present invention, as described 
below and as illustrated flowchart 510 of FIG. 25, enables a 
user to input data including a proposed trade of a financial 
instrument, wherein the financial instrument is advanta- 
geously defmed by symbology comprising a source field, a 
class field, a symbol field and a currency field, as indicated 
by block 512. This abbreviated format for identifying a 
financial instrument can then be easily transmitted to other 
users within the system 10, as indicated by block 514. At the 
receiving users trader workstation 20, the proposed trade can 
be viewed by the traders utilizing the symbology, as indi- 
cated by block 516. By defining the financial instrument 
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using the symbology of the present invention, the users can same price but with different credit preferences. The use of 
exchange a small amount of data that is translatable into a color coding enables the system 10 to preserve the anonym- 
detail description of a financial instrument that is relatively ity of the users while still enabling the viewing business 
complex This reduces communication and processing over- units to receive credit information about the bids and offers 
head of the system 10 and simplifies the user's efforts. 5 they are viewing. In the event the user is color blind, the 
Once the orders have been inputted via the symbology, the system 10 also includes the option to display small symbols 
market entry interface 250 displays the best bid and best next to each price to indicate the relevant credit status to the 
offer for each instrument, as well as the sum quantity viewer. 

available to trade at the best price and other relevant If the viewer wants to trade a green bid or offer, then the 

information. The order information (i.e., the bids and offers 10 system will permit this to be executed right away. Further, if 

for each instrument) is coded with the relevant credit the active counterparty to the transaction, that is, the viewer 

preferences, unless several prices are currently posted at the who hit the oid or lifted the offer, chooses to execute the full 

same price but have different credit status, in which case the size of the amount on offer or bid and there are no more 

market detail interface 302 should be used. This is signifi- ordcrs at thc samc P ricc > the viewer will be prompted with 

cantly different from some prior art systems which only 15 the abflily t0 ask thc olher counterparty to do more. This 

show the best dealable price. The system 10 presents the best will-do-more feature is preferably restricted to a predeter- 

price, irrespective of credit preferences or credit limits. mined time-limit in which thc receiver of the request must 

From market entry interface 250, it is possible for the user respond. The receiver of the request may agree to accept the 

to execute a trade' directly if the credit preferences of both increased quantity (or part of thc increased quantity) at thc 

parties permit. The user may also place a passive order from 20 previously agreed to price or the request will lapse. The 

the market entrv interface 250. will-do -more feature may be repeated as many times as the 

The user also has the option of activating a market detail users desire - ^ will-do-more feature does not necessarily 

interface 302 which enables a user to see the complete check credlt preferences once this process has begun 

picture (i.e., depth) of all the orders (e.g., bids and offers) because ^ users the identities of each other at this 

available on a particular financial instrument, coded with 25 P oinl - ms forces the users t0 take responsibility for further 

credit preference information. Thc market entry interface credit approval beyond the point of the initial trade amount. 

250 and the market detail interface 302 not only display the If the order being viewed by the user is yellow, then the 

best bid and offer, but each individual order in thc system 10 viewer wiU accept the poster but the poster will not accept 

individually. Through the market entry interface 250 and thc the viewer. In this case, the system 10 enables the viewer to 

market detail interface 302, the user is provided the ability 30 send a credit override message to the poster of the bid or 

to select not just the best bid or offer, but any bid and offer offer whereby the sender of ihe credit override reveals 

in the system 10. This is important because for credit his/her identity to the poster and asks the poster to reconsider 

reasons, the viewing counterparty may not wish, or may not whether or not the poster will do the requested trade with the 

be allowed to, trade a particular bid or offer. This means that viewer. In this case, the user which sent the credit override 

the best bid or offer in thc system 10 is not necessarily the 35 will be identified to the poster, but at no lime will the sender 

best bid or offer available to that counterparty. ° f the credit override find out who they revealed themselves 

Tbe credit preference information entered in the system t0 - If the P° ster chooses 10 acce P l the credit override, then 

10 by each user, as described above, is used by both the the P° ster ma y also choose 10 im P ose additional credit 

central processing center 12 and the transmitting business requirements on the viewer in order to accept the transac- 

unil servers 18 to prescreen the bids and offers, and to 4 0 tion ' lllcsc addltl0nal credlt requirements would be m thc 

market orders in the svstem 10 before they are viewed at the form of a standard mutual P ut clause in the confirmation of 

trader workstations 20 of the respective client sites 14. The thc trade - ^ viewer wlU havc the opportunity to either 

sensitive credit preference that indicates which counterpar- acce P l or declifi e the additional credit requirements. The 

ties are acceptable, and under what terms, is preferably credit override function does not in anyway change the 

maintained at the transmitting trader workstation 20 and the 4 5 credit P references which each user previously input into the 

central processing center 12. The other viewing users do not svstem 10 < ™ e crcdit overridc 1S Preferably on a per- 

receive or have access to the credit information of the other transaction basis. 

users. At the receiving business unit's server 18, a check is If lhG bid or offer viewed by the viewing trader is in red, 

performed to determine whether the receiving client site 14 then the viewer will not accept the poster. Despite the fact 

will accept the particular bid or offer from the transmitting 50 tha t the viewer knows he/she will not accept the poster, the 

legal entity. The summary and relevant data is transferred in viewer does not know which among the counterparties 

an encrypted form to trader workstations 20. The credit he/she will not accept is the poster. The viewer is thus not 

check may be re-performed at the time of a transaction by able to. identify the poster, preserving the anonymity of the 

the central site 14 and/or the central processing center 12. system 10. If the poster does not activate the credit override, 

The credit preference screening of the present invention 55 then 00 trade wil1 be abIe to take P lace - 

enables the display of all passive orders in the system 10 and If the bid or offer displayed is in blue, then the order is the 

their relevant credit status with regard to the viewer on both poster's own order. The system 10 does not prevent different 

the market entry interface 250 and the market detail inter- users within the same client site 14 from trading with each 

face 302 as follows: 1) green — this means that the viewer other. 

accepts the posting counterparty, and the posting counter- 60 From both the market entry interface 250 and the market 

party accepts the viewing counterparty; 2) yellow — this detail interface 302, it is also possible for the user to send a 

means that the viewing counterparty will accept the posting request-for-price message to the other counterparties that are 

counterparty but that the posting counterparty will not interested in the requested financial instrument. The request - 

accept the viewer; 3) red — that the viewer will not accept the for-price enables a user to anonymously broadcast to other 

poster; 4) blue— that the bid or offer being looked at is the 65 interested market participants. 

viewer's own; 5) white — used on the market entry interface With reference to FIG. 26, a flowchart 520 generally 

250 to denote when two or more orders are placed at the describes the steps of a trade. Initially, the first user and the 
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second user arc provided with essentially real-time order 
information regarding more than one financial instrument 
typically via the market entry interface 250, as indicated by 
block 522. The order information preferably includes a 
request to buy or sell a financial instrument such as an OTC 
derivative- At block 524, one of the first or second users 
initiates the trading process on an order selected from the 
order information provided by the other of the first or second 
users. The credit preference information of each user is then 
used to verify the trade eligibility of the first and second 
users with regard to one another based on the selected order, 
as indicated by block 526. One or both of the first and second 
users are then able to request an increase in the quantity of 
the order, as indicated by block 528. If an increase is 
requested, the request is process at block 530. Alternatively/ 
if there is no request to increase the quantity at block 528, 
it is then determined that block 532 if there is a request to 
negotiate terms of the order, and more particularly, the 
noncommercial terms of the financial instrument underlying 
the order. If there is a request to negotiate terms by one of 
the users, then the request is processed at block 534. If there 
is not a request to negotiate terms, then an acknowledgment 
is sent to both users signifying the execution of the trade, as 
indicated by block 536. 

The trade process as described above with reference to 
FIG. 26 can also be described from the perspective of the 
first and second users. For instance, with reference to FIG. 
27A, a flowchart 540 generally depicts the steps of a trade 
from the perspective of a passive user. Initially, at block 542, 
the credit preferences of the user are inputted and distributed 
to the other users for effectuating the credit preference 
screening. At block 544, the user sends an order to system 
10 for distribution to the other users requesting a trade on a 
financial instrument. The user that placed the order must 
then wait for another trader to hit or lift the passive order, 
thereby executing the trade. Both parties to the trade will 
receive an execution notification which will allow one or 
both users to request an increase in quantity, as determined 
by block 548. If this request is received from the party 
hitting or lifting the passive order, the first user accepts, 
denies, or amends the requested increase, as indicated by 
block 550. If there is no request to increase a quantity, then 
it is determined at block 552 whether there is a request to 
negotiate terms of the financial instrument. This feature 
allows the users to change the default values for the non- 
commercial terms of the financial contract, as indicated by 
block 554. Next, the first user will receive an acknowledg- 
ment of the execution of the trade with the second trader, as 
indicated by block 556. 

With reference to FIG. 27B, a flowchart 560 generally 
illustrates the steps of a trade from the perspective of the 
active user that lifted or hit the passive order. At block 562, 
the second user receives an order from the first user request- 
ing a trade on a financial instrument. The order is then 
checked for trade eligibility based upon the credit prefer- 
ences of the first and second users, as indicated by block 
564. The order is coded with appropriate credit information 
based upon the credit check, as indicated by block 566. The 
coded order is then presented to the second user based upon 
a preference or filter set by the second user to view orders 
of the present instrument, as indicated by block 568. The 
second user then initiates a trade by lifting or hitting the 
order, as indicated by block 570. In block 572, it is deter- 
mined if there is a request to increase quantity. If there is not 
a request to increase quantity, then the request is processed 
at block 574. If there is not a request to increase the quantity, 
then it is determined at block 576 whether there is a request 
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to negotiate terms of the financial instrument. This feature 
allows the users to change the default values for the non- 
commercial terms of the financial contract, as indicated by 
block 577. Next, an acknowledgment is received by the first 

5 and second users indicating that the trade has been executed, 
as indicated by block 578. 

Another feature of the present invention is the position 
discovery as illustrated by a flowchart 580 of FIG. 28. At 
block 582, risk position portfolios are received from the 

10 users of system 10. At block 584, relative position informa- 
tion is calculated for each user so that each user may be 
presented with possible trading combinations for their 
portfolios, and combinations of their portfolios against posi- 
tions from the other users. The possible trading combina- 

15 tions are coded with credit preference information in accor- 
dance with the present invention. It is then determined at 
block 586 if a switch is requested. If a switch is not 
requested, then the process ends. However, if a switch is 
requested at block 586, then a switch is executed at block 

20 588. The execution of the switch is performed in substan- 
tially the same manner as any other trade, as described 
above. Upon execution of the switch, the position informa- 
tion of each party to the switch is automatically updated to 
reflect the switch, as indicated by block 590. 

25 A blotter is provided to enable the user to keep track of all 
the orders he/she has inputted into the market. The blotter is 
preferably a screen whereby once it is activated, it displays 
all the outstanding orders a user has in the system. The 
blotter enables the user to monitor all his/tier outstanding 

30 orders in many different instruments conveniently in one 
place. Preferably, there are two types of blotters. The first is 
the outstanding order blotter 320 which offers several func- 
tions to the user for managing his/her .orders, such as the 
ability to change the price, or size of an order. This is 

35 accomplished through the use of dials on the windows which 
enable the user to quickly dial up or down the price without 
needing to cancel and then re-submit the order. This edit 
process shields the user from the complexity of order 
management regarding changed orders. This also prevents 

40 the user from accidentally having duplicate or no orders in 
the system 10. The outstanding order blotter 320 also 
enables the user to quickly suspend (or refer) all of his/her 
active orders in the system 10, and then re-input them one 
by one or delete them as necessary. Yet further, the oul- 

45 standing order blotter enables the trader to cancel one or all 
of his orders. The second type of blotter is the historical 
order blotter 330. From the historical order blotter, it is 
possible for the user to view all of his/her previously 
executed trades and the respective status, as well as those 

50 that have been canceled. 

In order to address the needs of interest rate swap traders 
and portfolio managers, the system 10 may include a func- 
tion known as the switch engine. The switch engine is 
implemented by a switch interface 400 and enables the user 

55 to input an entire portfolio of interest rale reset risks into the 
system 10, and then view out into the future for an unlimited 
time horizon on a daily basis. In a preferred embodiment, the 
user inputs the size (in millions) and the direction (receiving 
or paying) of the reset risks portfolio into the system 10 on 

60 a wide range of the most common interest indices (i.e., 1 
month U.S. dollar libor, 3 month U.S. dollar libor, 1 month 
DEM libor, etc.). The portfolio can be input either directly 
through the portfolio interface 380 (FIG. 21), or by upload- 
ing a file with the required information. Once the informa- 

65 tion has been input into the system 10, the user is then asked 
to confirm the input. Once this information has been 
confirmed, the user then has the ability to anonymously look 
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at his/her interest rate reset risk position relative to all other 
counterparties who have inputted such information to deter- 
mine based upon credit preferences, which trades are avail- 
able to him/her in the system 10 to off-set his/her interest 
rate reset risks. Once the user has located these trades, the 
user can then anonymously send a request-for-switch to the 
other counterparties in an attempt to initiate a trade. 

The system 10 further provides the functionality to permit 
the trading of various financial instruments via an auction 
function, as generally illustrated in a flowchart 600 of FIG. 
29. The system performs what is referred to herein as a two 
way Dutch auction with credit preferences. In this auction 
methodology, users submit orders into the auction giving 
both the price and the quantity at which they wish to trade, 
as indicated by block 602. The auction process then begins 
by calculating the price at which the most volume is traded, 
as indicated by block 604. This is called the auction-price. 
The auction-price is a fair price at which all transactions will 
be completed. In this calculation, the credit preferences of 
the various counterparties are not yet taken into account. At 
block 606, the system matches up orders such that all credit 
preferences are taken into account such that the minimum 
number of tickets are generated. The better submitted prices 
have priority, and all orders at the auction-price are prefer- 
ably filled in proportion to each other. In a preferred embodi- 
ment of the auction feature, the auction process could be 
conducted a few times a day in order to maximize liquidity. 
The system also offers the functionality to enable the user to 
trade forward rate agreement switches and other switch 
products in an auction environment similar to that described 
previously. 

The system then automatically generates a confirmation 
for each transaction and sends it electronically via email, 
fax, or another means to the counterparties of each executed 
transaction, as indicated by block 608. This unique confir- 
mation, process has been designed to use a standard and 
consistent format for all financial instruments. 

At this point, a more detailed description of the operation 
and functionality of the auction mechanism 34 is provided 
With reference to FIG. 30, the auction mechanism 34 
initially receives an order list from those traders wishing to 
participate in an auction, as indicated by block 620. The 
orders within the order list are separated into a BuyList and 
SellList, as indicated by block 622. At block 624, a price list 
is generated and sorted from highest price to lowest price. It 
is then determined at block 626 whether an auction will take 
place by determining if the price list is empty. If the price list 
is empty, then no auction takes place, as indicated by block 
628. If the price list is not empty, then the average auction 
price is calculated, as indicated by block 630, and as 
described in greater detail with reference to FIG. 31. Next, 
the orders are matched such that the minimum number of 
tickets are generated, taking into account the credit prefer- 
ences of all parties, as indicated by block 632, and as 
described in greater detail with reference to FIGS. 32Aand 
32B. Once the orders have been matched, a settlement list is 
generated, representing the execution of transactions via the 
option, as indicated by block 634. 

With reference to FIG. 31, the average auction price is 
calculated. In particular, beginning at block 640, the initial 
parameters are established, such as i« 1 , j= l , difference equal 
sl-bl, k=2, and N«size of price list. In addition, the total 
amount in the BuyList is B t , and the total amount in the 
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j=j+l, the parameter difference is set to difference^ 
difference+Bj, and the parameter k is set to k=k+l, as 
indicated by block 646. If not, then the parameter i is set to 
equal i=i+l, the parameter difference is set to difference= 
difference+S,, the parameter k is set to k=k+l, as indicated 
by block 646. The steps of block 642-648 are repeated until 
determination is made at block 642 that k=n+l. 

With reference to FIG. 32, the step of matching orders in 
an auction is described in greater detail. In particular, items 
in the BuyList and SellList are eliminated according to the 
average auction price, as indicated by block 650. It is then 
determined at block 652 whether the size of BuyList is 
greater than zero and the size of SellList is greater than zero. 
If one or the other is not greater than zero, then the 
settlement list is generated, as indicated by block 654. If 
both the BuyList and SellList are greater than zero, then the 
parameter Bsum is set to equal the total volume in BuyList 
and Ssum is set to equal the total volume in SellList, as 
indicated by block 656. It is then determined at block 658 if 
Ssum is greater than the Bsum. If it is, then the parameter 
listl is set to equal SellList and the parameter list2 is set to 
equal BuyList, as indicated by block 660. Next, the order! 
parameter is set to equal to the first order in listi and orderl 
is removed from listl, as indicated by block 662. The 
maximum/minimum and credit rules are then applied to 
search the BuyList for matching order2. A matching order2 
is located and a trade is generated between orderl and 
order2, as indicated by block 666. If at block 668 it is 
determined that Ssum is not greater than Bsum, then param- 
eter listl is set to equal BuyList and list2 is set to equal 
SellList, as indicated by block 668. Next, orderl is set to 
equal the first order in listl and orderl is removed from 
Listl, as indicated by block 670. Next, list2 is searched in 
order to find a match to orderl using the maximum- 
minimum rule and the credit preferences associated with the 
orders, as indicated by block 672 and described in greater 
detail with reference to FIG. 33. A trade is then generated 
between orderl and order2, as indicated by block 674. 

With reference to FIG. 33, the application of the 
maximum-minimum rule and credit rules satisfying an order 
are described in greater detail. Initially, it is noted that the 
parameter volume is equal to the volume of an order, and 
more particularly, of orderl. At block 680, it is initially 
determined whether the parameter volume equals 0 for 
orderl. If it does not equal zero, then it is determined at 
block 682 whether list2 is empty. If list2 is not empty, then 
list2 is searched for the first matching order, as indicated by 
block 684. Once a matching order is located, then the 
volume traded will equal to the minimum as defined by the 
credit preferences of either party, the volume of ordert, or the 
volume of order2, as indicated by block 686. It is then 
determined if the trade volume is 0, as indicated by block 
688. If the trade volume is 0, then the process begins again 
at block 680. If the trade volume is not equal to 0, then a 
trade is generated and placed in the settlement list, as 
indicated by block 690. In addition, at block 692, order2 is 
removed from list2. Next, the volume of orderl and order2 
are updated by setting the respective volumes to the previous 
volumes minus the trade volume, as indicated by block 694. 
It is then determined at block 696 if the volume of order2 is 
equal to zero. If it is not, then order2 is placed back in a 
temporary list and a credit of the parties placing orderl and 
order2 are updated, as indicated by block 698. Once the 
volume of orderl is determined to be zero, then it is 
determined at block 702 whether the temporary list is empty. 
If it is not, then the temporary list is merged with the 
BuyList, as indicated by block 704. Subsequently, the pro- 
cess ends. 



10 



20 



25 



30 



SellList is S*, 



Next, it is determined at block 642 
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The operation of the central processing center 12 is now 
generally described with reference to FIG. 34 which func- 
tionally depicts the group server mechanism 32, the auction 
mechanism 34 and switch mechanism 35, the market inven- 
tory module 38, the execution module 40, and the settlement 5 
module 42. A legend 710 is provided to the denote the flow 
of the different orders, interactive and switch orders, auction 
orders, and switch auction orders, between the group server 
mechanism 32, the auction mechanisms 34, the market 
inventory module 38, the execution module 40, and the 10 
settlement module 42. Beginning with the interactive/switch 
order generated by the user at one of the trader workstations 
20, the central processing center 12 initially receives the 
interactive/switch order 712 at the group server mechanism 
32, At the group server mechanism 32, an order record is 15 
created, the credit preferences of the users are checked to 
assure the trade conforms to the current credit preferences of 
the users, and a transaction order is created. If the order is 
passive, then it flows through to the market inventory 
module 38 where is it distributed to the trader workstations 20 
20 for viewing via respective market detail interfaces 302 of 
the users logged on the system 10. If the order is active, then 
it flows through to the market inventory module 38 where 
order matching occurs if the order is a part of an auction, and 
pre-execution of the order also occurs. Pre-execution may 25 
include, for instance, a back-end credit check to ensure up to 
date credit preferences and to accommodate complex 
checks. Further, in a manner that is transparent to the users, 
the market inventory module 38 requires the trader work- 
stations 20 of the respective users that are a party to the trade 30 
to respond with an acknowledgement to assure that there has 
been no loss of communication or that one of the users has 
not logged off. Upon receiving the acknowledgement, the 
market inventory module 38 executes the trade and then 
publishes the updated volume and status to the users logged 35 
on to the system 10 for viewing via respective command 
center interface 130 of the users. 

Next, the execution module 40 will, upon request of one 
of the users that were a party to the trade, enables the 
quantity of the trade to be increased via the will-do-more 4 n 
feature. This will typically be the case unless the full 
quantity of the instrument is transacted. Otherwise, the 
execution module will initiate the confirmation process 
which includes an opportunity for either of the users that 
were a party to the trade to enter into term negotiations. 45 

The order the flows through to the settlement module 42 
which initiates the settlement process. The settlement mod- 
ule allows for symbol explosion by the users to view the 
exact terms of the contract. Further, a settlement module 
calculates the commission based upon the order which ends 50 
the process, thereby noting the end of the order execution 
process. 

In the case of an auction, an auction order 714 received by 
the auction mechanism 34. The auction module 34 enables 
auction and switch auction functionality of the present 55 
invention. The auction module initially receives the auction 
orders 714 a from a plurality of users during a countdown to 
the actual auction time. Once the auction time has arrived 
and the auction orders have been submitted, the auction 
mechanism 34 performs the auction matching with credit 60 
preferences of the users taken into account. The auction 
matching performed by the auction mechanism 34 is in 
accordance with the present invention, that is, the auction is 
based on a fair price and executed for a maximum volume 
traded with a minimum number of tickets generated. From 65 
the auction mechanism 34, once the counterparties have 
been matched the market inventory server essentially treats 
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the resulting auction orders as though it would an 
interactive/switch order 712. In particular, the market inven- 
tory module 38 perform order matching, pre-execution, 
acknowledgement, trade execution and volume/data pub- 
lishing. 

The auction order 712 is then delivered to the execution 
module 40. At the execution module 40, an auction order and 
a switch auction order are traded slightly different. For 
instance, an auction order may be increased in quantity by 
one of the users that is a party to the auction order via the 
will-do-more. On the other hand, switch auction orders do 
not make use of this feature, but will go directly to the 
confirmation process. Further, where auction orders may 
also have their non- commercial terms negotiated using the 
term negotiation feature, switch auction orders will flow to 
the settlement module 42 directly after confirmation. Both 
auction orders and switch auction order are then received by 
the settlement module 42 which performs essentially the 
same operations to the auction order as it does to an 
interactive/switch order 712. Specifically, the settlement 
order 42 provides similar explosion and commissioned 
calculations which complete the order process. 

In the drawings and specification, there have been dis- 
closed typical preferred embodiments of the invention and, 
although specific terms are employed, they are used in a 
generic and descriptive sense only and not for purposes of 
limitation, the scope of the invention being set forth in the 
following claims. 

Wherefore, the following is claimed; 

1. A system for facilitating electronic trading of 
derivatives, comprising: 

a communications network operationally interconnecting 
a first trader and a second trader to a central processing 
center; 

a market module associated with said central processing 
center that provides said first and second traders with 
essentially real-time order information regarding more 
than one class of derivative, said order information 
including requests to buy derivatives and requests to 
sell derivatives, wherein said derivatives are defined 
utilizing symbology; 

a trader module associated with each of said first and 
second traders for receiving said real-time order infor- 
mation from said central processing center and present- 
ing said real -time order information to said first and 
second traders; 

a credit preference module associated with each of said 
first and second traders, said credit preference modules 
presenting to respective said first and second traders a 
respective trade eligibility for each of said requests to 
buy and said requests to sell, wherein said trade eligi- 
bility is based upon credit preferences of both said first 
and second traders, and wherein said credit preferences 
are defined using a multi-rule measurement of credit 
risk; and 

an execution module associated with said central process- 
ing center that processes a trade initiated by one of said 
first and second traders which desires to trade on an 
order posted in said order information by the other of 
said first and second traders. 

2. The system of claim 1, wherein each of said first and 
second traders provides said credit preference module with 
credit preference information regarding the other of the first 
and second traders. 

3. The system of claim 1, wherein said multi-rule mea- 
surement of credit risk comprises at least one of a risk 
equivalent rule and a maturity rule. 
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4. The system of claim 1, further including a switch 
module that receives derivative positions from skid first and 
second traders, and determines relative position information 
for said first and second traders. 

5. The system of claim 4, wherein said switch module 5 
takes into consideration credit preference information pro- 
vided by each of said first and second traders when deter- 
mining said position information, whereby said position 
information includes potentially offsetting positions. 

6. The system of claim 1, wherein said trader module 
presents said order information utilizing instrument symbol- 
ogy. 

7. The system of claim 1, wherein said execution module 
generates an acknowledgment at completion of a trade 
between said first and second traders. 

8. The system of claim I, wherein said order information 15 
is available for a definable period set by one of said first and 
second traders which posted said order information. 

9. The system of claim 1, wherein said execution module 
enables said first and second traders to negotiate contract 
terms of a trade based on said order information. 20 

10. The system of claim 1, wherein said execution module 
provides said one of said first and second traders that 
initiated a trade based on said order information an option to 
request a larger quantity order. 

U. A system for facilitating derivative trading, said sys- 2 s 
tern having a plurality of interconnected first and second 
traders that exchange order information, each of said first 
and second traders connected to a central processing center, 
said central processing center comprising; 

a market module that provides said first and seconid 3Q 
traders with essentially real-time order information 
regarding more than one derivative, said order infor- 
mation including requests to buy derivatives and 
requests to sell derivatives, and wherein said deriva- 
tives are defined utilizing symbology; 

an execution module associated with said central process- 35 
ing center that can process a trade initiated by one of 
said first and second traders which desires to trade on 
an order proposed in said order information by the 
other of said first and second traders; 

a group server that receives credit preference information 40 
of said first trader toward said second trader and said 
second trader toward said first trader, wherein said 
credit preference information is defined using a multi- 
rule measurement of credit risk; and 

an interface to a communications network that intercon- 45 
nects said plurality of first and second traders to said 
central processing center. 

12. The system of claim 11, further comprising a browser- 
based interface to said system, wherein said market module 
and said execution module present order information col- 50 
lected at said central processing center to said first and 
second traders via said browser-based interface. 

13. The system of claim 12, wherein said browser-based 
interface includes filter options for screening orders pre- 
sented to said first and second traders based on an underlying 55 
financial instrument. 

14. The system of claim 12, wherein said browser-based 
interface automatically receives updated order information 
from said central processing unit for presentation to said first 
and second traders. 60 

15. The system of claim 11, wherein said execution 
module presents said first and second traders with an option 
to increase trade quantity. 

16. The system of claim 11, wherein said execution 
module presents said first and second traders with a trade 65 
window providing an option to negotiate contract terms of 
said trade. 
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17. The system of claim 11, wherein said multi-rule 
measurement of credit risk comprises at least one of a risk 
equivalent rule and a maturity rule. 

18. A method for facilitating electronic trading of deriva- 
tives between a first party and a plurality of potential traders 
including a second party, all of which are interconnected by 
a central processing center of a computer network, said 
method comprising the steps of: 

receiving at the central processing center an order from 

the first party requesting a trade; 
sending the order from the first party to the potential 

traders anonymously requesting the trade on a 

derivative, wherein the derivative is defined utilizing 

symbology; 

presenting the order to the plurality of potential traders 
substantially simultaneously, wherein the presented 
order includes trade eligibility of each respective 
receiving potential trader and the first trader, wherein 
said trade eligibility is determined using a multi-rule 
measurement of credit risk; and 

receiving an acknowledgment from the second trader 
initiating a trade with the first trader on the order. 

19. The method of claim 18, further comprising the step 
of receiving a request from the second trader to increase a 
quantity of the order. 

20. The method of claim 19, further comprising the step 
of responding to the request for an increased quantity. 

21. The method of claim 18, further comprising the step 
of receiving credit preferences defined using the multi-rule 
measuement of credit risk. 

22. The method of claim 18, further comprising the step 
of canceling the order. 

23. The method of claim 18, further comprising the step 
of canceling all outstanding orders. 

24. The method of claim 18, further comprising the step 
of or suspending all outstanding orders, 

25. The method of claim 18, further comprising the step 
of presenting a blotter interface to the first trader that 
presents active orders of the first trader. 

26. The method of claim 18, further comprising the step 
of presenting a blotter interface to the first trader that 
presents executed orders of the first trader. 

27. The method of claim 18, further comprising the step 
of inputting credit preference data regarding the potential 
traders for distribution to the potential traders. 

28. The method of claim 18, wherein the step of present- 
ing the order to the plurality of potential traders comprises 
presenting the order to potential traders based on order filters 
associated with respective potential traders. 

29. The method of claim 18, further comprising the step 
of presenting the second trader with a trade window requir- 
ing the second trader to accept the order before the trade is 
executed. 

30. The method of claim 29, further comprising the steps 
of presenting the second trader with a trade window that 
enables the second trader to decrease a transaction quantity 
of the order before executing the order. 

31. The method of claim 18, further comprising the step 
of presenting one of the first trader and the second trader 
with a term negotiation window for increasing a transaction 
quantity of the order. 

32. The method of claim 18, further comprising the step 
of presenting one of the first trader and the second trader 
with a term negotiation window to enable the one of the first 
trader and the second trader to initiate negotiation of con- 
tract terms of the trade, wherein the contract terms are 
selected from the group consisting of legal, month-end, 
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settle, first setting, at-the-moncy symbol, spot, base, and 
bond exchange. 1 

33. The method of claim 18, wherein the step of present- 
ing the order includes presenting the order, wherein the 
multi-rule measurement of credit risk comprises at least one 5 
of a risk equivalent rule and a maturity rule. 

34. A method for facilitating derivative trading between a 
first party and a second party, comprising the steps of: 

receiving an order from the first party to the second party 
requesting a trade on an derivative, wherein the deriva- 10 
live is defined utilizing symbology; 

checking the order for trade eligibility based on credit 
preferences of the first and second parlies, wherein said 
credit preferences are defined using a multi-rule mea- 
surement of credit risk; 15 

encoding the order with the appropriate trade eligibility 
information based on said step of checking the order; 

presenting the encoded order to the second party based on 
a preference of the second trader to receive orders on 2 o 
the derivative; and 

initiating a trade between the first and second parties if the 
second party initiates a trade. 

35. The method of claim 34, further including the step of 
presenting the second party with order information regard- 25 
ing outstanding orders of the second party. 

36. The method of claim 34, further including the step of 
presenting detail market information to the second party 
regarding market activity in a single financial instrument. 

37. The method of claim 36, wherein said detailed market 30 
information includes quantity, bid price, ask price, and 
encoded credit preference information. 

38. The method of claim 34, further including the step of 
presenting market entry information to the second party 
regarding financial instruments selected by the second party. 35 

39. The method of claim 38, wherein said market entry 
information includes best bids, best asking prices, and 
encoded credit preference information. 

40. The method of claim 34, further including the step of 
receiving an acknowledgment to the first and second traders 40 
if a trade is executed. 

41. The method of claim 34, further including the step of 
querying the second party to determine if the second party 
would like to increase the quantity traded. 
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42. The method of claim 34, further including the step of 
negotiating non-commercial terms of the financial instru- 
ment traded. 

43. The method of claim 34, further including the steps of 
receiving interest rate swap positions from the first and 
second parties, and determining relative position informa- 
tion for the first and second parties. 

44. The method of claim 34, wherein the financial instru- 
ment is defined by an instrument symbology. 

45. The method of claim 34, wherein said step of checking 
the order for trade eligibility includes the step of screening 
the order by maturity or risk equivalent. 

46. A computer program product for use with a data 
processing system for facilitating derivative trading, said 
computer program product comprising, 

a computer usable medium having computer-readable 
code means embodied in said medium, said computer- 
readable code means comprising: 

computer readable code means for receiving an order 
from the first party to the second party requesting a 
trade on derivative, wherein the derivative is defined 
utilizing symbology; 

computer readable code means for checking the order for 
trade eligibility based on credit preferences of the first 
and second parties, wherein said credit preferences are 
defined utilizing a multi-rule measurement of credit 
risk; 

computer readable code means for encoding the order . 

with the appropriate trade eligibility information based 

on said step of checking the order; 
computer readable code means for presenting the encoded 

order to the second party based on a preference of the 

second trader to receive orders on the derivative; and 
computer readable code means for initiating a trade 

between the first and second parties if the second party 

initiates a trade. 

47. The computer program product of claim 46, wherein 
the multi-rule measurement of credit risk comprises at least 
one of a risk equivalent rule and a maturity rule. 
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